# Users can front run the signature of the paymaster operation leading to some problems

MagicSpend reuses one signature for withdraw and validatePaymasterUserOp, so a user can front-run withdraw and consume the nonce, reverting the paymaster op.

- Payout: Contest reward
- Severity: medium
- Program: Coinbase
- Credited: Jorgect
- Disclosed: 2024-05-01
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-03-coinbase-findings/issues/39
- Library page: https://bugbountylibrary.com/r/c4%3A2024-03-coinbase%3AM-02
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:race-window technique:source-review vuln:dos vuln:race-condition vuln:signature-replay

**Target:** MagicSpend paymaster contract (EIP-4337)
**Root cause:** The withdraw() function and validatePaymasterUserOp() consume the same signed WithdrawRequest/nonce, so a direct withdraw call invalidates the signature before the paymaster validation runs.
**Steps:**
1. Build a WithdrawRequest {asset, amount, nonce, expiry, signature} signed by the user.
2. Submit a UserOperation with paymasterAndData = abi.encodePacked(address(magicSpend), abi.encode(WithdrawRequest)).
3. Before the bundler includes the userOp, call `magic.withdraw(WithdrawRequest)` directly with higher gas to land first.
4. The nonce is consumed; subsequent `validatePaymasterUserOp(userOp, userOpHash, maxCost)` reverts (InvalidSignature/consumed nonce).
**How found:** Code reading: noticed validatePaymasterUserOp and withdraw() both validate the same WithdrawRequest signature/nonce, hypothesized a race between direct withdraw and bundler-included userOp, confirmed with a Foundry test.
**Exploitation:** User submits a paymaster-sponsored userOp carrying the withdraw signature, then front-runs it with a direct withdraw() call from their smart account/EOA owner, consuming the nonce and forcing the paymaster validation to revert. Funds are only withdrawn once; the harm is repeated reverting userOps attributed to the paymaster.
**Escalation:** Repeating the front-run across many userOps could get the paymaster banned by bundlers (reputation/DoS), but no double-spend of funds.
**Insight:** When a paymaster and a direct withdrawal path share one signed struct/nonce, check whether an attacker can land the direct path first to invalidate the sponsored op — signature/nonce reuse across entry paths is the tell.