ERC-4337 EntryPoint v0.9: Fixing a Griefing Vector in Account Abstraction

The Ethereum Foundation's current thinking on making accounts post-quantum (PQ) secure leans heavily on account abstraction (AA). The idea is straightforward: if an account's transaction validation is programmable, then we can upgrade that validation over time, including adding post-quantum signature checks, without changing the account's address.

This comes with a real trade-off. As soon as you move authorization into a programmable execution pipeline, you are no longer only trusting the signature scheme. You are also trusting the system that takes a signed intent, moves it through new infrastructure, and finally turns it into an on-chain call. Last week, a newly disclosed ERC-4337 vulnerability from the Ethereum Foundation and Trust Security was a good reminder of that. The issue does not allow stealing funds directly, but it can make valid, correctly signed AA transactions revert, while still charging the user (or the paymaster) for the gas. The mitigation is in EntryPoint v0.9 (released Nov 2025).

To see why this class of bug exists, it helps to compare the execution model with externally owned accounts (EOAs). In the EOA world, the user signs a transaction and broadcasts it. When it executes, it is a top-level call that starts from a clean slate. In ERC-4337 account abstraction, the user instead signs a UserOperation, which is closer to a signed instruction that will later be executed by the EntryPoint contract via a bundler. That indirection is the whole point. It enables smart accounts, paymasters, batching, and flexible validation. It also means there is now a path between the user signing intent and the target contract call actually running, and that path has security properties of its own.

The following shows a high-level sequence diagram of an EOA transaction. The final image in this post shows a full end-to-end diagram for an account abstraction transaction.

For this AA vulnerability, the core issue is that Alice signing a UserOperation does not fully control the circumstances under which her action runs. It locks in what she asked to do (which contract to call, what data to pass, and the limits around gas), but it does not guarantee that her call will be executed as a clean, standalone action. On Ethereum, that matters because a single transaction can contain multiple contract calls, and earlier calls can set short-lived flags or conditions that change whether later calls succeed or revert.

Defenses like reentrancy guards depend on that. A reentrancy guard is just a lock that says "if we are already inside this function, reject any second entry until we exit". That is usually protecting a contract from an attacker calling it twice in the same transaction in a dangerous way. But if an attacker can make a victim's call happen while they are already "inside" the contract, that lock becomes a reliable way to force a call to revert.

Trust Security found that EntryPoint versions before v0.9 allow a griefing attack where an attacker creates a temporary "must revert" condition in a target contract (for example by tripping a reentrancy guard), then forces a victim's valid UserOperation to execute while that condition is still active. The UserOperation is correctly signed and validates normally, but it is executed at the wrong moment, so the inner call reverts and the victim (or their paymaster) still pays the gas.

Here is a step-by-step trace of the attack:

• Alice signs a valid UserOp that will call intended_contract (for example, a withdrawal).
• Eve learns about that UserOp before it executes, either from the ERC-4337 UserOp mempool (gossiped between bundlers/relays) or by decoding a pending bundler handleOps transaction from the public transaction mempool.
• Eve sends a transaction that calls an attacker contract, evil_contract.
• evil_contract calls into intended_contract first, specifically to create a temporary condition that will make a second entry or dependent check fail right now. The simplest example is entering a reentrancy-guarded function so the lock is held, but the same idea applies to other temporary state manipulations (for example, momentarily changing liquidity or price so a check reverts).
• While Eve is still "inside" that same transaction and call stack, evil_contract calls EntryPoint.handleOps(...) and includes Alice's signed UserOp as the payload.
• EntryPoint validates Alice's UserOp successfully (signature, nonce, and the rest all check out) and then attempts to execute the inner call to intended_contract.
• This inner call reverts because it is being executed in the middle of Eve's call stack, while the destination contract is in the temporarily "blocked" condition Eve created.
• Alice (or her paymaster) still pays the gas for this failed execution, so Eve can repeat the attack and make specific AA-driven interactions unreliable or prohibitively expensive.

Here is a sequence diagram for the same attack:

The timing is the whole point. The attacker is not trying to permanently change contract state. They are trying to create a temporary condition that only exists during their own execution, then force Alice's UserOp to run during that window. If Alice's UserOp executes later, in its own top-level transaction context, the temporary condition is gone and the call would succeed.

Scope-wise, this does not affect every UserOp. It affects classes of interactions where a temporary state change can force a revert, with reentrancy-guarded flows being the obvious class and flash loan-style manipulations being another. Simple transfers and many wallet-internal actions are not impacted, but the affected set still covers a meaningful portion of AA DeFi usage because these defenses and checks are everywhere.

EntryPoint v0.9 fixes the issue by restricting how handleOps and handleAggregatedOps can be called. It enforces that they must be invoked by an EOA in a top-level transaction context, which prevents an attacker contract from calling into EntryPoint mid-execution. That removes the attacker's ability to force a user's signed operation to run inside an attacker-controlled call stack, which is the core trick that made this griefing vector possible.

The first thing to say is that this bug is not something that only matters if you care about post-quantum. However, most credible Ethereum PQ paths involve more account abstraction, not less. If you want to keep a stable account address while changing what authorizes that account over time, smart accounts are the natural place to do it. That is crypto-agility at the account layer: not just swapping a signature scheme, but having an account framework that can evolve. If that is the direction, audits cannot stop at asking "did we implement ML-DSA correctly?" They also need to cover the dependency graph that actually turns authorization into execution, including the AA execution rules and how they interact with real contracts. This disclosure is the kind of bug that lives in that dependency boundary, not in the signature scheme.

There is also a real trade-off to think about if AA gets pushed closer to the protocol. One proposal being discussed is EIP-8141 Frame Transactions, which is positioned as both a post-quantum migration path and a stronger form of account abstraction at the transaction format level. If something like that were enshrined, fixes for issues in the account pipeline would likely become more coordinated but also more coupled to protocol upgrade cadence. Today, EntryPoint fixes can ship as new contract versions, but users can end up pinned to old ones. Protocol-level changes could reduce that fragmentation, but they would also raise the bar for making changes quickly. I do not think one is inherently better than the other, but these are important considerations beyond which signature schemes should Ethereum support.