Six mistakes in ERC-4337 smart accounts
Trail of Bits identified six common vulnerability patterns in ERC-4337 smart accounts during their audits. These vulnerabilities, ranging from incorrect access controls and incomplete signature validation to state modification issues and replay attacks, can allow attackers to drain funds or hijack account ownership.
Authors: Trail of Bits
Key Takeaways
- ERC-4337 smart accounts introduce programmability risks where a single bug can be as catastrophic as leaking a private key.
- Incorrect access control on the execute function allows unauthorized actors to drain wallet funds.
- Failing to cryptographically bind gas fields (like preVerificationGas) in signature validation allows attackers to inflate fees and drain ETH.
- State modifications during validateUserOp can be overwritten due to batch semantics, leading to authorization bypasses.
- ERC-1271 signatures must be domain-separated by chainId and contract address to prevent cross-chain or cross-account replay attacks.
Affected Systems
- Ethereum Smart Contracts
- ERC-4337 Smart Accounts
- ERC-7579 Modules
- ERC-7702 Accounts
Attack Chain
Attackers exploit vulnerabilities in ERC-4337 smart contract implementations to drain funds or hijack accounts. By calling an unprotected execute function, an attacker can directly transfer assets. Alternatively, by manipulating unsigned gas fields like preVerificationGas in a UserOperation, a malicious bundler can inflate fees and drain ETH. Attackers can also replay ERC-1271 signatures across different chains or accounts if domain separation is not properly implemented.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No specific detection rules are provided in the article, as the focus is on smart contract code auditing and secure implementation patterns.
Detection Engineering Assessment
EDR Visibility: None — EDR tools monitor OS-level activity on traditional endpoints, not blockchain smart contract executions or Web3 transactions. Network Visibility: Low — While network monitoring can capture RPC calls to Ethereum nodes, it cannot easily parse complex smart contract state changes without specialized blockchain analytics. Detection Difficulty: Hard — Requires specialized Web3 monitoring tools to trace internal transactions, UserOperation parameters, and signature validations on-chain.
Required Log Sources
- Blockchain RPC Logs
- Smart Contract Events
- Web3 Mempool Data
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Monitor for UserOperation submissions where gas fields like preVerificationGas are unusually high compared to network averages, indicating potential fee inflation by a malicious bundler. | Blockchain RPC Logs | Execution | Medium |
| Look for direct calls to smart account execute functions originating from addresses other than the designated EntryPoint contract. | Smart Contract Events | Execution | Low |
| Identify identical signature payloads being submitted across multiple chains or different smart account addresses, indicating a potential ERC-1271 replay attack. | Blockchain RPC Logs | Credential Access | Low |
Control Gaps
- Traditional Web2 WAFs
- Endpoint Detection and Response (EDR)
- Standard Network IDS/IPS
Key Behavioral Indicators
- Unusually high preVerificationGas values in UserOperations
- Direct calls to execute() bypassing the EntryPoint contract
- Replayed signatures across different chainIds or verifyingContracts
False Positive Assessment
- Low
Recommendations
Immediate Mitigation
- Audit existing ERC-4337 smart accounts against the six identified vulnerability patterns.
- Ensure the execute function is strictly restricted to the EntryPoint contract or vetted executor modules.
Infrastructure Hardening
- Implement EIP-712 typed data for all ERC-1271 signature validations to ensure domain separation by chainId and contract address.
- Ensure validateUserOp is stateless and does not write to storage to prevent batch execution race conditions.
- Make postOp minimal, bounded, and non-reverting, treating it as best-effort bookkeeping rather than core invariant enforcement.
User Protection
- Use the EntryPoint's userOpHash for validation to cryptographically bind all gas fields.
- For ERC-7702, restrict initialization to msg.sender == address(this) to prevent frontrunning.
Security Awareness
- Educate smart contract developers on the differences between EOA and contract account security models.
- Incorporate ERC-4337 specific checks into the CI/CD pipeline and pre-merge gates.
MITRE ATT&CK Mapping
- T1190 - Exploit Public-Facing Application
- T1550 - Use Alternate Authentication Material
- T1550.001 - Application Access Token
