Improving UserOperation Execution Safety in EntryPoint v0.9
In collaboration with the TrustSec team, whose review and support helped improve the security of ERC-4337
An issue was identified in earlier versions of ERC-4337 that could allow a malicious actor to intentionally cause certain account-abstraction transactions to revert and pay for gas, even though they were valid and correctly signed.
This behavior is not universal and does not affect all UserOperations. It applies only under specific conditions, which are important to understand.
This is a censorship and griefing vector, not a fund-theft vector.
This behavior was fixed in EntryPoint v0.9.
Root cause and attack vector
The ERC4337 implementation operated under a hidden assumption that the UserOperation binds the protocol to run the user transaction only as intended by the user. Despite the signature binding transaction data such as destination, passed data and gas limit, it does not enforce that the transaction is run in an isolated context (without prior code execution). However, smart contract security facilities such as reentrancy guards (developed prior to AA) assume an attacker cannot manipulate state within the call stack prior to an incoming user transaction. An attacker observing such transactions could frontrun their execution, lock the destination contract and submit the UserOperation to the EntryPoint. This would cause the inner transaction to revert while paying for the spent gas, griefing AA users.
How UserOperations can be observed
UserOperations may become observable to third parties in two distinct ways:
Source UserOps from the ERC-4337 UserOperation mempool, where UserOperations are gossiped offchain between bundlers and relays.
Source UserOps by decoding pending handleOps transactions from the public transaction mempool, where a bundler submits a normal Ethereum transaction that contains the full UserOperation payload in calldata.
Both mechanisms are valid and widely used today, and the issue applies in either case if the UserOperation is visible prior to execution.
Which transactions are affected
Only specific classes of transactions are impacted, in particular:
transactions that interact with protocols using reentrancy protection
transactions whose execution can be made to revert through temporary state changes, such as flashloan-driven price or liquidity manipulation.
Simple transfers, internal account logic, and many other UserOperations are not affected. Despite the impact being limited to specific transaction classes, those classes cover a substantial share of potential DeFi activity, and, it could escalate to user-facing disruption including temporary or prolonged fund unavailability (i.e., effective freezes) through griefing of withdrawal flows, among others.
Practical impact today
At the time of discovery, ERC-4337 mempool usage was still nascent and actively growing, rather than saturated. As a result, the real-world impact was bounded, but the issue is important to address before broader adoption amplifies its effects.
Resolution and next steps
EntryPoint v0.9 enforces that handleOps and handleAggregatedOps may only be invoked by EOAs in a top-level transaction context, preventing execution of UserOperations inside attacker-controlled call frames.
The fix does not indicate an emergency situation, but it does make upgrading to v0.9 time-sensitive and important for wallets, bundlers, and infrastructure providers as account abstraction adoption continues to grow.
Bug bounty and responsible disclosure
This high severity issue was identified and responsibly disclosed through the Account Abstraction bug bounty program on Hackenproof. We would like to thank TrustSec for their thorough analysis and for coordinating closely with the team throughout the disclosure process. The report was handled in line with our standard disclosure practices, with publication timing coordinated to allow wallets, bundlers, and infrastructure providers time to upgrade. This process reflects the ongoing value of independent security research and the role of the bounty program in strengthening our ecosystem.
important to understand.
This is a censorship and griefing vector, not a fund-theft vector.
This behavior was fixed in EntryPoint v0.9.
Root cause and attack vector
The ERC4337 implementation operated under a hidden assumption that the UserOperation binds the protocol to run the user transaction only as intended by the user. Despite the signature binding transaction data such as destination, passed data and gas limit, it does not enforce that the transaction is run in an isolated context (without prior code execution). However, smart contract security facilities such as reentrancy guards (developed prior to AA) assume an attacker cannot manipulate state within the call stack prior to an incoming user transaction. An attacker observing such transactions could frontrun their execution, lock the destination contract and submit the UserOperation to the EntryPoint. This would cause the inner transaction to revert while paying for the spent gas, griefing AA users.
How UserOperations can be observed
UserOperations may become observable to third parties in two distinct ways:
Source UserOps from the ERC-4337 UserOperation mempool, where UserOperations are gossiped offchain between bundlers and relays.
Source UserOps by decoding pending handleOps transactions from the public transaction mempool, where a bundler submits a normal Ethereum transaction that contains the full UserOperation payload in calldata.
Both mechanisms are valid and widely used today, and the issue applies in either case if the UserOperation is visible prior to execution.
Which transactions are affected
Only specific classes of transactions are impacted, in particular:
transactions that interact with protocols using reentrancy protection
transactions whose execution can be made to revert through temporary state changes, such as flashloan-driven price or liquidity manipulation.
Simple transfers, internal account logic, and many other UserOperations are not affected. Despite the impact being limited to specific transaction classes, those classes cover a substantial share of potential DeFi activity, and, it could escalate to user-facing disruption including temporary or prolonged fund unavailability (i.e., effective freezes) through griefing of withdrawal flows, among others.
Practical impact today
At the time of discovery, ERC-4337 mempool usage was still nascent and actively growing, rather than saturated. As a result, the real-world impact was bounded, but the issue is important to address before broader adoption amplifies its effects.
Resolution and next steps
EntryPoint v0.9 enforces that handleOps and handleAggregatedOps may only be invoked by EOAs in a top-level transaction context, preventing execution of UserOperations inside attacker-controlled call frames.
The fix does not indicate an emergency situation, but it does make upgrading to v0.9 time-sensitive and important for wallets, bundlers, and infrastructure providers as account abstraction adoption continues to grow.
Bug bounty and responsible disclosure
This high severity issue was identified and responsibly disclosed through the Account Abstraction bug bounty program on Hackenproof. We would like to thank TrustSec for their thorough analysis and for coordinating closely with the team throughout the disclosure process. The report was handled in line with our standard disclosure practices, with publication timing coordinated to allow wallets, bundlers, and infrastructure providers time to upgrade. This process reflects the ongoing value of independent security research and the role of the bounty program in strengthening our ecosystem.