The known attacks on x402, and what fixes each one

Why is there good research on this?#

Because x402 is open, widely deployed and handles money, which is the combination that attracts scrutiny. Several independent analyses were published through 2026, findings were disclosed, and fixes landed in the public repository.

That is the system working. A payment protocol that nobody had attacked would be one nobody had looked at.

1. Settlement preemption#

The problem. Anyone who observes a signed EIP-3009 authorisation can submit it on-chain before the intended facilitator does. Researchers demonstrated this on Base Sepolia: the attacker's transfer consumes the nonce, so the legitimate facilitator's settlement then fails.

Note what the attacker gains. The funds still go to the payee named in the signature, which cannot be altered. What the attacker achieves is disruption: the seller's settlement fails, and a seller that already served the resource has been paid by a transaction it cannot connect to the request.

The fix. Settlement functions should check that the caller is the facilitator the client authorised. Where the token contract cannot enforce that, the seller's reconciliation has to tolerate a settlement arriving from an unexpected sender.

2. Replay before settlement#

The problem. The on-chain nonce prevents double-spend after settlement. Before it, nothing in the protocol stops a server being handed the same valid payment repeatedly. A server that releases its resource on verification alone, without recording the payment identity first, serves every time.

This is the most commonly skipped check and the easiest to exploit. It needs no cryptography, only a captured payment header and a replay.

The fix. Record the payment identity atomically before releasing the resource. An open pull request against the x402 repository proposes exactly this as a server-side extension, and the ordering is the whole of it: record, then serve.

3. Resource substitution#

The problem. A payment is an authorisation for an amount to an address. If the server does not check the resource field, a payment signed for a cheap endpoint is a valid payment for an expensive one. The buyer pays your lowest price and calls your highest-cost route.

The fix. Bind the payment to the resource and verify the binding on every request. A string comparison, and skipping it is a pricing bypass rather than a theoretical issue. Adding x402 to an API covers where it goes.

4. Free delivery from non-atomic verification#

The problem. A 2026 study described a facilitator whose /verify was stateless and did not reserve the payment nonce, while /settle was not atomically bound to a specific verification result. A merchant could deliver a protected resource more than once under one buyer authorisation.

This is the facilitator-side cousin of problem 2, and it means a seller doing everything right can still be exposed by its facilitator's design.

The fix. Choose a facilitator that documents its replay handling, and keep your own nonce tracking regardless. Defence in depth here is cheap.

5. Signature validation at the facilitator#

The problem. The same study reported an ERC-6492 related asset-theft issue in a high-volume facilitator, which did not cryptographically validate the wrapper or the inner signature during verification and then trusted attacker-supplied deployment metadata at settlement.

The fix. Entirely on the facilitator's side, and it was disclosed and fixed. The lesson for a seller is that facilitator choice is a security decision, not only an availability and pricing one. Facilitators compared covers what to look for.

What should a seller do?#

Five things, roughly in order of value per hour spent.

Short validity windows deserve a note. An authorisation is dangerous only while it is valid, so a sixty-second window and a six-hour window are very different exposures to a captured header. The cost is that slow clients fail, so measure your real sign-to-retry latency and set the window above its tail rather than at a round number.

What should a buyer do?#

Less, because the buyer's exposure is smaller. Two things worth doing anyway:

Sign for the smallest amount and the shortest window that works. A leaked authorisation can only transfer what it says, to the address it names, before it expires.

Verify settlement independently. Resolve the transaction hash from the receipt header rather than trusting the seller's 200. A success response is a claim; the chain is the record.

Frequently asked questions#

Can a facilitator steal my payment?#

Not the funds. The payee is inside the signed message and cannot be changed. It can decline to settle, settle late, or fail, which is why verification is not completion.

Were these found in production or in theory?#

Both. Several were demonstrated against live implementations, including one on Base Sepolia with a published trace, and disclosed to the parties involved.

Does the protocol need to change?#

The fixes are mostly implementation-side. Work on replay-protection extensions continues in the public repository, which is where to look for the current state rather than any article.

Is x402 less safe than card rails?#

Different, not strictly worse. Cards carry fraud and chargeback risk and a dispute process. x402 removes the chargeback and gives a final settlement, which moves risk from the seller to the buyer. Each is safer at the thing the other is bad at.

How do I know my facilitator has fixed these?#

Ask, and read its documentation. A facilitator that does not discuss replay handling anywhere has not told you whether it does it.

Where to check this yourself#

Receipts and verification documents how Roundhouse's own facilitator handles verification and settlement, and errors covers the refusal cases so you can assert against them. The testnet matrix in testing x402 includes the replay case specifically, because that is the one you have to try deliberately to find.