Skip to content
.ca
4 minhigh

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.

Conf:highAnalyzed:2026-03-19reports

Authors: Trail of Bits

Source: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

HypothesisTelemetryATT&CK StageFP 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 LogsExecutionMedium
Look for direct calls to smart account execute functions originating from addresses other than the designated EntryPoint contract.Smart Contract EventsExecutionLow
Identify identical signature payloads being submitted across multiple chains or different smart account addresses, indicating a potential ERC-1271 replay attack.Blockchain RPC LogsCredential AccessLow

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