High-Severity ERC-4337 Account Abstraction Vulnerability: A TrustSec Case Study

Introduction

This case study documents a high-severity vulnerability identified by the TrustSec team and disclosed through the Account Abstraction bug bounty program on HackenProof. The issue did not allow fund theft but enabled a denial-of-service and griefing scenario affecting certain classes of Account Abstraction transactions under specific conditions. HackenProof acted as the coordination channel, supporting responsible communication with the Ethereum Foundation and allowing mitigations to be implemented prior to public disclosure. The technical details and impact described in this case study are primarily based on the Ethereum Foundation’s public disclosure of the issue.

Account Abstraction and ERC-4337: Background

ERC-4337 introduces Account Abstraction to Ethereum without requiring changes at the consensus layer. Instead of relying on externally owned accounts, users submit UserOperations that are collected and executed by bundlers through a shared EntryPoint contract. This design enables advanced wallet logic, such as custom authentication, batched transactions, and gas sponsorship, while remaining compatible with existing Ethereum infrastructure.

A core principle of ERC-4337 is the absence of trust assumptions toward bundlers. UserOperations are expected to be safe even when observed or ordered by potentially adversarial actors, and signatures bind the intended transaction parameters such as destination, calldata, and gas limits. However, while these guarantees cover what code is executed, they do not fully constrain the execution context in which it runs. This distinction becomes important when Account Abstraction interactions reach beyond simple transfers and interface with existing DeFi protocols that were designed under different execution assumptions.

The Vulnerability: Root Cause and Impact

Overview

The vulnerability affected earlier versions of ERC-4337 and made it possible for an attacker to intentionally cause certain Account Abstraction transactions to revert while still incurring gas costs. The transactions in question were valid and correctly signed, and the issue did not enable fund theft or unauthorized access. Instead, it introduced a denial-of-service and griefing scenario that could be triggered under specific and observable conditions.

Root Cause

The underlying cause was an implicit assumption about how UserOperations are executed. While a UserOperation signature binds the intended transaction parameters—such as the target contract, calldata, and gas limits—it does not guarantee that execution occurs in a fully isolated context.

Some smart contract security mechanisms, including widely used reentrancy guards, were designed with the assumption that no attacker-controlled code can run earlier in the same call stack. Under the Account Abstraction execution model, this assumption does not always hold. As a result, pre-existing safety checks could be influenced by prior state changes without violating signature validity.

Observability and Exploit Conditions

For the issue to be exploitable, the UserOperation needed to be observable before execution. This could occur in two common scenarios:

• when UserOperations are propagated through the ERC-4337 off-chain mempool, or
• when a bundler submits a handleOps transaction to the public Ethereum mempool containing the full UserOperation payload.

In these cases, an attacker could observe a pending operation, temporarily modify relevant contract state, and then allow the UserOperation to be executed. The modified state could cause the inner transaction to revert once processed by the EntryPoint, resulting in a failed operation that still paid for gas.

Affected Scope and Practical Impact

The impact was limited to specific classes of transactions. In particular, interactions with contracts using reentrancy protection or those sensitive to temporary state changes—such as certain DeFi withdrawals or liquidity-related operations—could be affected. Simple transfers, internal wallet logic, and many other Account Abstraction use cases were not impacted.

At the time the issue was identified, usage of the ERC-4337 mempool was still at an early stage. This limited the practical exposure, but the findings highlighted an important consideration for Account Abstraction as adoption grows and interactions with existing DeFi infrastructure become more common.

Resolution and Key Takeaways

Resolution and Mitigation

Following responsible disclosure through the Account Abstraction bug bounty program on HackenProof, the issue was addressed in coordination with the Ethereum Foundation. The mitigation was implemented in EntryPoint v0.9, which enforces that handleOps and handleAggregatedOps can only be invoked by externally owned accounts in a top-level transaction context. This change prevents UserOperations from being executed within attacker-controlled call frames, removing the conditions required for the described griefing scenario.

The update was not treated as an emergency fix, but upgrading to v0.9 was considered time-sensitive for wallets, bundlers, and infrastructure providers as Account Abstraction usage continues to expand.

Responsible Disclosure and Outcome

The report was handled in line with standard disclosure practices, allowing relevant ecosystem participants time to assess impact and deploy mitigations before public discussion. TrustSec’s findings were acknowledged through the Account Abstraction bug bounty program, and additional coordination with affected applications helped reduce potential downstream risk. The process demonstrated the value of structured disclosure channels for protocol-level research, particularly for emerging standards.

Conclusion

This case highlights the role of independent security research in identifying edge cases as new protocol standards such as Account Abstraction are adopted. The coordinated disclosure and response process demonstrates how open engagement with external researchers and structured bug bounty programs support timely mitigation and contribute to the resilience of shared infrastructure. By addressing the issue early and transparently, the Ethereum ecosystem reinforced a security-first approach that prioritizes user safety and long-term protocol robustness as Account Abstraction adoption continues to grow.