Five attacks on x402: when AI agents pay, the cross-layer seams leak

What is this?

On May 12, 2026, researchers from Ohio State University, CSIRO and the University of Manchester posted Five Attacks on x402 Agentic Payment Protocol (arXiv:2605.11781). x402 is an open standard — championed by Coinbase — that revives the long-dormant HTTP 402 Payment Required status code so software agents can pay for APIs and content on the fly: the server answers a request with 402, the agent attaches an X-PAYMENT header, an off-chain facilitator verifies and settles the payment on-chain, and the resource is released.

The paper’s thesis is structural. x402 couples synchronous HTTP authorization with asynchronous blockchain settlement, and that seam — present in neither classic web payments nor pure on-chain payments — is where the protocol leaks. The authors formalize four security properties (authorization soundness, payment–service correspondence, replay resistance, and facilitator k-atomicity), then show that x402 violates them in both design and deployed implementations.

How it works

The work characterizes five attacks across four classes. None require breaking cryptography; they exploit gaps between the HTTP layer and the chain.

Class                         Attack          Core failure
----------------------------  --------------  -------------------------------------------
I  Settlement-path mismatch   I-A Revert-grant  resource granted before payment is final
                              I-B Preemption    caller-unbound settlement consumed by an
                                                observer before the real facilitator
II Replay / idempotency       II               reusable X-PAYMENT payload -> many grants
III Web-layer handling        III              CDN cache leakage of paid content; proxy/
                                                header ambiguity
IV Server selection           IV               discovery layer steers the agent toward a
                                                malicious paid endpoint

The replay result is the most vivid: when a server releases the resource before atomically recording a payment identity, one valid X-PAYMENT payload can be reused, and on a live endpoint the authors observed 248 grants from a single payment. Settlement-path inconsistencies let an agent receive a resource that is never finally paid (revert-grant reproduced up to 5.18% even with honest facilitators). At the discovery layer — before any payment begins — manipulating server metadata biased agent selection toward an adversarial endpoint up to 71.8% of the time, and a five-identity Sybil flood reached 60.2%.

No reproducible payloads are reproduced here; the canonical reference is the paper. The findings were validated on a testbed of 25,000+ payment requests across 48 configurations (Hardhat/Anvil and Base Sepolia) plus four production endpoints, with 95% Wilson confidence intervals.

Why it matters

Agentic commerce is moving from demo to deployment, and x402 is one of its load-bearing rails. The attack surface is novel because the trust boundary runs across protocols: the X-PAYMENT header behaves like a bearer capability that ordinary HTTP infrastructure — proxies, CDNs, caches — will happily replay or store, while the actual money settles seconds later on a chain that the web layer cannot roll back. A cache misconfiguration becomes a payment bypass; a missing idempotency key becomes free service at scale.

A cross-implementation audit of three open-source SDKs and four live endpoints turned up 11 vulnerabilities, including grant-before-settle behavior in a third-party Python SDK, missing resource-identifier binding, fire-and-forget settlement, and absent Cache-Control headers. This is not a theoretical model: it is shipping code. Related work the same quarter — Hardening x402 on plaintext metadata leakage and the SoK on autonomous agents in agentic commerce — points the same way: the payment layer is now a first-class part of the agent threat model.

Defenses

There is no single patch — these are protocol- and deployment-level classes. The mitigations the paper proposes, and standard hardening for anyone running x402:

1. Make settlement atomic with the grant (two-phase settlement). Do not release the resource under optimistic execution. Bind the on-chain caller, facilitator, resource, and the access decision into one atomic object so a revert cannot leave a granted-but-unpaid state.

2. Enforce mandatory idempotency with resource binding. Record a payment identity before releasing anything, and bind each payment to a specific resource identifier. This closes the replay/idempotency class that produced 248 grants from one payment.

3. Treat the X-PAYMENT header as a bearer secret in your web stack. Set explicit Cache-Control: no-store on payment-gated responses, audit CDN and proxy behavior for cache leakage, and apply canonical encoding so header/proxy ambiguity cannot be exploited by parser differentials.

4. Harden agent-side discovery. Do not let unverified metadata or registration volume drive endpoint selection. Use reputation, signed registrations, and Sybil-resistance in Bazaar-style discovery so an agent cannot be steered to a malicious paid server before payment even starts.

5. Minimize and protect payment metadata. Per Hardening x402, fields like resource_url, description and reason travel in plaintext to the facilitator — filter or redact PII before execution.

6. Audit your SDK, not just the spec. Most of the 11 findings were implementation bugs. Test for grant-before-settle, missing idempotency, and absent cache headers in whatever x402 library you deploy.

Status

Item	Reference	Date	Notes
Five Attacks on x402 Agentic Payment Protocol	arXiv:2605.11781	2026-05-12	Five attacks / four classes; formal model + testbed
Replay yielding multiple grants	Same paper	2026-05-12	248 grants from one payment on a live endpoint
Discovery-layer bias	Same paper	2026-05-12	71.8% metadata manipulation; 60.2% 5-Sybil flood
SDK / endpoint audit	Same paper	2026-05-12	11 vulnerabilities across 3 SDKs + 4 endpoints
Responsible disclosure	HackerOne #3679163/#3679179/#3679220	2026	Reported privately to Coinbase before publication
Hardening x402 (metadata/PII)	arXiv:2604.11430	2026-04	Plaintext metadata leakage and pre-execution filtering

The lesson generalizes beyond one protocol: when an agent’s authorization lives in HTTP but its money lives on a chain, security holds only if the two are bound atomically. Everything the attacks exploit lives in the gap between them.