Account Abstraction Security: ERC-4337 Pitfalls in Production

By 2026, account abstraction (ERC-4337 in production for two years, ERC-7702 widely adopted post-Pectra) has shifted the wallet landscape. Smart contract wallets, gasless transactions, social recovery, and session keys are no longer experimental. They are how a meaningful chunk of users now interact with on-chain protocols. This piece walks through the security pitfalls we see in production AA deployments, and what an audit of an ERC-4337 stack should actually cover.

The new trust model

A traditional EOA-controlled wallet has one trust assumption: the holder of the private key. Compromise the key, drain the funds. Account abstraction expands that into a programmable model with multiple actors:

• The smart contract account itself, with custom validation logic.
• The bundler, which packages user operations and submits them to the EntryPoint.
• The paymaster, which sponsors gas (or accepts ERC-20 payment) on behalf of the user.
• Session keys / sub-accounts, with scoped permissions and time bounds.
• Social recovery guardians, who can rotate the master key.

Each is a new surface. The wallet drainer of 2026 doesn't always need the user's signature: it might exploit an over-permissioned session key, a buggy paymaster, or a recovery path that bypasses intended protections.

Pitfall 1: paymaster economic griefing

A paymaster can sponsor gas for any user operation it accepts. The classic attack: a malicious user submits operations that consume the paymaster's deposit faster than the legitimate user base does, draining the dApp's treasury.

What to audit on a paymaster:

• Validation cost is bounded. If validation can call into arbitrary contracts (state reads, oracle calls), the bundler may not include the op due to gas estimates. But a malicious op can still consume the bundler's verification budget.
• Per-user rate limits. A paymaster that doesn't track per-sender consumption is trivially drainable.
• Acceptance rules. Paymasters that accept any operation are paymasters that go bankrupt. Validate the target contract, the function selector, the calldata shape.
• Withdrawal protection. The paymaster owner should not be able to drain the paymaster faster than users in flight expect.

A well-known production paymaster lost $200k in a 2025 incident from a missing per-op gas check. The bug was in fewer than 10 lines of Solidity.

Pitfall 2: validation-phase reentrancy and storage access

The ERC-4337 spec restricts what a wallet's validation function can do, specifically which storage slots it can read and which other contracts it can call. The reason: bundlers need to be able to predict whether an op will succeed without executing it.

Wallets that violate the validation restrictions (intentionally or via composition with library code) get rejected by reputation-tracking bundlers. But more subtly: wallets that technically comply with the rules can still be designed in ways that make the validation behaviour different from execution. That gap is exploitable.

What to audit:

• Validation must not depend on mutable global state that can change between validation and execution.
• Validation must not call into external contracts whose return values affect the validation outcome (the spec restricts this, but composition can sneak it through).
• The wallet's validateUserOp and execute paths must agree on what is "the same operation": different signature schemes here are an entry point.

Pitfall 3: session keys with too-broad scope

Session keys are the AA feature that most directly shifts UX: a dApp can request the user grant a scoped, time-bounded key for a series of operations (a game session, a trading session) without prompting for every transaction.

The common mistakes:

• Scope is too broad. "Allow this dApp to call any contract" is functionally equivalent to "give this dApp your private key for the duration."
• Scope expressions are wrong. ABI-decoded scope rules with off-by-one errors are common. A session key meant to allow "trades up to $100" that allows "trades up to $1,000,000" is a bad day.
• Revocation is not tested. Some session-key implementations have on-chain revocation paths that don't propagate immediately. Revoke + assume revoked is a security gap.
• Key storage on the dApp side. A session key compromised on the dApp's frontend (XSS, malicious extension) is functionally equivalent to a key compromise on the user side.

Pitfall 4: social recovery edge cases

Social recovery (a set of guardians who can collectively rotate the master key) is a powerful UX feature with real security trade-offs.

What to audit:

• Guardian onboarding. Are guardians verified out-of-band, or can they be added by the wallet owner alone (which collapses social recovery to the original key)?
• Guardian compromise. If a single guardian is compromised, what is the impact? Threshold + timelock is the standard answer.
• Race conditions. Recovery flows that involve a timelock plus a guardian quorum can have race conditions where a guardian is added or removed during a recovery in flight.
• Recovery abuse. Some implementations let guardians initiate recovery without the owner's consent. With enough guardian collusion, this is the master key.

Pitfall 5: ERC-7702 transient delegation

ERC-7702 (live since Pectra) lets an EOA temporarily delegate to a smart-contract wallet for a single transaction. It is a powerful UX win, bringing AA features to existing EOAs without migration. It is also new attack surface.

What to audit:

• Delegated code. The contract being delegated to runs with the EOA's authority. If it has any "drain to caller" function, the EOA is now drainable by anyone who can trigger it.
• Delegation revocation. EIP-7702 delegations are persistent until explicitly revoked. A user who delegates once and never revokes is permanently subject to the delegated contract's logic.
• Phishing surface. The phishing attack of 2026 is "sign this innocent-looking 7702 delegation": the resulting delegation grants the malicious contract permanent control until revoked.

What a credible AA audit covers

An audit of an ERC-4337 / 7702 stack should explicitly answer:

1. Does the wallet's validateUserOp comply with the ERC-4337 storage and call restrictions?
2. Does the paymaster (if present) have per-sender rate limits and bounded validation cost?
3. Are session keys' scope expressions correctly ABI-decoded and bounded?
4. Are recovery paths timelocked, threshold-gated, and revocation-tested?
5. (For 7702) is the delegated contract's interface deliberately minimal and replay-protected?
6. Are there any "fast paths" (admin functions, emergency pauses) that bypass the intended trust model?

Building production AA

Account abstraction is genuinely good for UX. The security bar is also higher than EOA-controlled wallets, because the wallet is a smart contract and bugs in it carry the same consequences as bugs in any DeFi contract.

If you are shipping AA infrastructure (a wallet provider, a paymaster, a session-key system), the smart contract audit should be scoped explicitly to the AA risks above, not just the wallet's "core" logic. The interesting attack paths in 2026 are the ones the spec doesn't forbid but the implementation gets wrong.