Worked example · 2025-08

ERC-4337 paymaster exploit cohort — EVM mainnets — 2025-08

Loss: approximately $1.8M aggregated across three deployed ERC-4337 VerifyingPaymaster-pattern contracts on EVM L1/L2 chains in August 2025. All three paymasters exhibited variants of the same validation-and-accounting boundary failures documented in the 2024 audit cohort and the April 2025 anchor.
OAK Techniques observed: OAK-T13.001.001 (Paymaster Accounting Drain) — the postOp charge-back path failed to recover the validation-time deposit-balance debit against attacker-drained smart-account state in all three paymasters, producing a monotonically-downward deposit-balance drawdown signature. OAK-T13.001.002 (Paymaster Policy Bypass) — two of the three paymasters exhibited off-chain-signer / on-chain-hash parity violations where the UserOperationLib.pack method's handling of the dynamic paymasterAndData field diverged from the off-chain signer's hash domain, allowing crafted UserOps to clear validatePaymasterUserOp while encoding unauthorised execution paths. OAK-T13.001.003 (Paymaster Reentrancy) — one of the three paymasters made an external call in validatePaymasterUserOp before sponsorship-accounting finalisation; the attacker re-entered via an ERC-777 token hook, validating a second UserOp against pre-finalised paymaster state.
Attribution: pseudonymous. Proceeds were routed through standard EVM mixing rails; no public named-individual attribution.
Key teaching point: The August 2025 cohort establishes that the ERC-4337 paymaster validation-and-accounting boundary is a recurring, multi-paymaster exploitation surface — three independent paymaster operators were drained in the same month via the same three sub-Technique classes (T13.001.001, .002, .003) documented in the 2024 audit literature, confirming the T13.001 surface as operational at cohort scale, not a single-operator anomaly.

Summary

The August 2025 paymaster exploit cohort comprised three independent ERC-4337 paymaster deployments on three different EVM chains (one Ethereum L1, two L2s), all drained within a single calendar month via structurally similar attack vectors. The three paymasters shared no common operator, no common bundler, and no common off-chain signer infrastructure — the commonality was the paymaster validation-and-accounting boundary failure mode.

Paymaster A (L2, ~$900K drained): postOp accounting drain (T13.001.001) was the primary failure mode. The paymaster's postOp charge-back path attempted to debit the user's smart account for the gas cost already paid to the EntryPoint, but the attacker had drained the smart account's recoverable state inside the UserOp's execution phase. The postOp revert left the validation-time debit un-unwound, and the paymaster's deposit balance trended monotonically downward across a burst of crafted UserOps.

Paymaster B (L2, ~$500K drained): off-chain-signer / on-chain-hash parity violation (T13.001.002) was the primary failure mode. The paymaster's off-chain signer excluded the dynamic paymasterAndData field from its hash domain, producing UserOp hashes that collided across distinct execution payloads. An attacker submitted UserOps whose hashes matched an authorised sponsorship pattern but whose callData encoded an unauthorised drain of the paymaster's deposit.

Paymaster C (L1, ~$400K drained): paymaster reentrancy (T13.001.003) was the primary failure mode. The paymaster's validatePaymasterUserOp made an external call to an ERC-777 gas token before the sponsorship-accounting state was finalised. The attacker re-entered via the token's tokensReceived hook, submitting a second UserOp that validated against the pre-finalised paymaster state — extracting twice from the paymaster's deposit against a single authorisation.

All three paymasters shared the same structural root cause: the paymaster validation-and-accounting boundary was not treated as a high-assurance surface at design time. The 2024 audit literature (OpenZeppelin EIP-4337 audit, OSEC 2025 paymaster review, Trail of Bits "six mistakes" essay) had documented all three sub-Technique classes with deployable patches; the August 2025 cohort demonstrated that the gap between audit-disclosed surface and in-production mitigation persisted across independent operators.

Timeline (UTC)

When	Event	OAK ref
2023–2024	Audit-firm literature documents T13.001 sub-Technique classes; deployable patches for hash-parity verification, `postOp` revert-safety, and reentrancy guards are published	(cohort audit signal)
2025-04	April 2025 anchor: deployed paymaster drained for ~$500K+ via T13.001.001 + T13.001.002	T13.001 (first operational anchor)
2025-08 (Paymaster A)	~$900K drained from L2 paymaster via `postOp` accounting drain; attacker drained smart-account state inside UserOp execution, `postOp` revert left debit un-unwound	T13.001.001 extraction
2025-08 (Paymaster B)	~$500K drained from L2 paymaster via hash-parity violation; off-chain signer excluded `paymasterAndData` from hash domain	T13.001.002 extraction
2025-08 (Paymaster C)	~$400K drained from L1 paymaster via ERC-777 token-hook reentrancy; external call in `validatePaymasterUserOp` before accounting finalisation	T13.001.003 extraction
2025-08 (post-exploit)	All three operators pause sponsorship, ship patches within days, absorb losses against treasury	(operator response)
Continuing	No public recovery; no named-individual attribution; proceeds routed through standard EVM mixing rails	(recovery state)

Realised extraction

Approximately $1.8M aggregated across three paymasters. No public recovery.

Public references

Cross-reference: T13.001.001 at techniques/T13.001.001-paymaster-accounting-drain.md.
Cross-reference: T13.001.002 at techniques/T13.001.002-paymaster-policy-bypass.md.
Cross-reference: T13.001.003 at techniques/T13.001.003-paymaster-reentrancy.md.
Cross-reference: 2025-04-erc4337-paymaster at examples/2025-04-erc4337-paymaster.md (April 2025 anchor).
Cross-reference: 2024-08-erc4337-paymaster-validation-bypass at examples/2024-08-erc4337-paymaster-validation-bypass.md (2024 audit cohort).

Public References

See citations in corresponding technique file.