1inch
Audited by Socket on Sep 17, 2026
8 alerts found:
SecurityAnomalyx7SUSPICIOUS: the core swap/limit-order behavior matches the 1inch trading purpose, but the skill enables autonomous financial actions, defaults to auto-approval, routes sensitive API traffic through an unspecified proxy, depends on a configurable wallet service, and instructs installation/use of another skill with broad policy implications. Not confirmed malware, but the operational and credential-routing footprint is high-risk for an agent skill.
The code is a legitimate-looking 1inch cross-chain trading integration, not an apparent malware or supply-chain payload. It communicates with the expected 1inch API and wallet runtime and handles protocol secrets as part of Fusion+ settlement. No credential theft, suspicious exfiltration, obfuscated payload, persistence, or system damage is evident. The main security risk is that externally returned transaction or typed-data payloads are forwarded to wallet signing/submission with limited local validation, combined with weak amount and Solana input validation. Wallet policy enforcement and transaction destination/value validation should be relied upon or added.
The fragment appears to implement a 1inch limit-order integration rather than malware. It contains no evident credential theft, arbitrary code execution, persistence, or unauthorized network exfiltration. However, it performs high-impact wallet signing and transaction submission, trusts unvalidated order metadata from an external API, embeds an opaque fixed extension and fee recipient, and uses a signing domain inconsistent with the declared limit-order protocol. These issues require protocol-level and wallet-policy review before production use. The missing asyncio import also prevents normal wallet-dependent execution.
The fragment appears to be a legitimate 1inch Fusion+ cross-chain swap client, not intentionally malicious. Its primary risks are financial-impact trust in remote API-provided transaction data, plaintext local storage of swap secrets, and insufficient validation of token and amount inputs. Review _oneinch_lib and enforce transaction target/chain/value validation before allowing wallet submission. Protect or encrypt the order file and restrict its permissions.
The fragment appears to implement intended 1inch wallet integration rather than malware. It performs external API queries and can initiate approvals and swaps, but those actions are explicit financial operations and are routed through the wallet runtime, including policy error handling. The main security concern is the potential for unlimited approvals by default and reliance on the unseen wallet runtime and 1inch client to validate transaction destinations and enforce authorization. No credential theft, data exfiltration, reverse shell, persistence, obfuscated payload, or destructive behavior is present in the supplied code.
No direct evidence of malware or deliberate data theft appears in this fragment. The code is a legitimate-looking 1inch swap CLI, but it performs real blockchain transactions and can issue an unrestricted approval when --auto-approve is used. The external helper modules must be audited, especially wallet_broadcast(), approve_tx(), swap_tx(), endpoint handling, and credential storage. The fallback sys.path modification is an unusual supply-chain consideration but is not sufficient by itself to establish malicious behavior.
The visible code is a straightforward blockchain token-approval CLI and contains no clear malware indicators or obfuscation. It does perform a consequential financial operation: by default it may grant unlimited token spending authority to the router selected by approve_tx(). Review _oneinch_lib and verify router/token validation before use. The security concern is authorization risk rather than apparent malicious behavior.
The code implements opt-in-looking telemetry/reporting controlled by environment variables, but it sends trade events and CONTAINER_JWT to any configured endpoint without enforcing HTTPS or host allowlisting. This could enable data or credential disclosure if the environment is misconfigured or compromised. No clear malicious payload, hardcoded exfiltration destination, or other malware behavior is evident in this fragment.