# Paymaster ETH can be drained with malicious sender

VerifyingSingletonPaymaster reuses paymaster signatures without tracking use, so a malicious account can replay one signed UserOp to drain paymaster ETH deposits.

- Payout: Contest reward
- Severity: high
- Program: Biconomy
- Credited: taek
- Disclosed: 2023-03-03
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2023-01-biconomy-findings/issues/151
- Library page: https://bugbountylibrary.com/r/c4%3A2023-01-biconomy%3AH-05
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:signature-replay

**Target:** ERC-4337 verifying singleton paymaster contract (validatePaymasterUserOp)
**Root cause:** validatePaymasterUserOp validates the paymaster's signature over the UserOp hash but never records that the hash was consumed, so the same signed UserOp can be submitted repeatedly.
**Steps:**
1. Observe a sponsored tx from a well-behaved account using VerifyingSingletonPaymaster, capturing paymaster signature sig X.
2. Delegatecall Upgrader to replace the sender account with MaliciousAccount.sol that omits nonce checks.
3. Replay the same UserOp with sig X repeatedly via entryPoint.
4. Each replay consumes paymaster prefund/deposit while attacker gains little.
**How found:** Noticed validatePaymasterUserOp is non-view per ERC-4337 and has no replay protection on the signed hash, then reasoned that a nonce-free malicious account could reuse a captured paymaster signature.
**Exploitation:** Attacker upgrades their smart account to a malicious implementation lacking nonce validation, then resubmits the previously signed UserOp with the same paymaster signature over and over; each execution charges the paymaster's prefunded ETH deposit, draining it.
**Insight:** In ERC-4337, paymaster validation is stateful (non-view); any signature over a UserOp hash must be explicitly marked consumed, since the account controls nonce enforcement and can drop it.