For most of its life, x402's security has been examined the way early crypto was: one vendor disclosure at a time, one "we found a bug and patched it" at a time. That changed in May 2026, when a group of researchers published the first systematic security analysis of x402 — not as a single artifact, but as a stack of an HTTP semantic, per-chain schemes, and a long tail of SDK and deployment choices.
The paper is "Free-Riding the Agentic Web: A Systematic Security Analysis of x402 Payments" (Ling, Huang, Du, Chen, Zhou, Wu, and Wang; submitted May 29, 2026, revised June 22, 2026). It opens by noting the protocol has crossed 130 million all-time transactions and is embedded in Google Cloud, Cloudflare, and Stripe — then walks through four flaw classes whose measured resource-leakage ratios reach 100%. All findings were disclosed to the affected vendors before publication.
We run a live x402 deployment, so we read this the way you'd read a fire-safety report on your own building. This post is a plain-English map of the attack surface and the fixes, because every agent-payment builder is going to need it.
The paper grounds the whole analysis in five invariants that any x402 payment is supposed to satisfy:
| Invariant | Meaning |
|---|---|
| I1 Payment Integrity | If a resource was delivered, a confirmed on-chain transfer from payer to merchant exists. |
| I2 Value Consistency | The transaction value covers the negotiated price. |
| I3 Context Binding | A payment authorization is cryptographically bound to the resource it pays for. |
| I4 Authorization Uniqueness | A nonce-bearing authorization is consumed exactly once, across all concurrent requests. |
| I5 Execution Conservation | Expensive execution begins only after payment is confirmed or locked. |
Each of the four flaw classes below is a violation of one or more of these invariants, resolved to the layer that's responsible — protocol, SDK, or deployment.
The signed authorization commits to the merchant, the value, a nonce, and an expiry — but not to the resource. The paper calls this a "floating authorization": a valid signature obtained for resource r_a can be detached and re-attached to any other request r_b at the same price, and the verification step can't tell the difference. The authors reproduced this in 100 out of 100 rounds.
What makes it a stack problem rather than a single bug is where the failures live in each SDK: TypeScript and Python omit the resource check entirely, Java verifies a mutable JSON field it shouldn't trust, and Go blindly trusts the stateless facilitator. The fix is protocol-level, not per-implementation: cryptographic context binding — extend the EIP-712 schema so the payer signs Sign(merchant, value, nonce, expiry, H(Method∥URI∥Body)). Then replaying against a different resource is invalid regardless of implementation quality.
Verification and settlement are deliberately decoupled in the verify-settle flow, and a window opens between the facilitator's validity report and chain confirmation. Multiple requests carrying the same one-time authorization can all clear verification before any of them reaches the on-chain consumption step. The reproduction: fifty rounds of twenty concurrent requests produced duplicate delivery in 6% of rounds — two distinct HTTP 200 responses with different payloads, while only one settlement confirmed. A related omission: one Python adapter gates settlement on a 2xx status, so a 302 redirect gets served without settling at all.
The fix is stateful nonce linearization: a pending-state layer at facilitator ingress using an atomic check-and-lock. A nonce is accepted only if its state is null, moves to pending on acceptance, then to used after on-chain confirmation — so only the first request to grab the lock proceeds.
Under the upto dynamic-pricing scheme, the payer signs a spending cap rather than an exact amount, and per-deduction settlements carry no nonce. Verification is a non-binding snapshot check of remaining allowance — it "degrades from a cryptographic proof of a specific payment event to a stateful check of a remaining limit." A TOCTOU race follows: the payer sets allowance to the floor and fires N concurrent requests whose aggregate cost is far above the cap. All pass the snapshot check and stream output; on-chain, only the first few settle and the rest revert — after full delivery.
The measured numbers are stark. A 50-request burst delivered 47,277 wei of value but settled only 1,057 wei — a leakage ratio of 97.76%. The "long-context" variant, one request whose cost exceeds remaining allowance, drives the ratio to ~100%. The fix is reserve-commit two-phase locking: escrow the cap before execution, then release the actual cost to the merchant and refund the difference on completion, so the merchant never subsidizes compute.
This one is a deployment default, not a smart-contract flaw: rate-limit asymmetry between service ingress and settlement egress. Verification ingress is provisioned high, but settlement defaults to around 10 tx/s. An adversary floods valid requests; every one is verified and served, but settlement requests beyond the limit are rejected with 429. A 50 req/s burst against that default settled only 5 of 50 requests — 86.95% leakage, rising to 100% when the limit blocks everything. There's also a client-driven variant: terminate the TCP connection before the merchant's settlement callback fires, and the streamed output is consumed without any settlement.
The fix is failure-closed design: couple the rate limiter and billing to request ingress, reserving billing capacity before forwarding to the inference engine. The principle the paper states is worth quoting: reliability issues should result in denial of service, not denial of payment.
The paper composes three deployment-layer defenses to bound the residual risk once F1 is fixed at the protocol level:
The composed result: zero successful attacks in 500 adversarial trials, attacker leverage inverted from 8.7× to 0.9× at only 2.8% overhead. The paper also proves a structural limit worth internalizing: no output-only pay-per-token pricing can be both fair to honest users and bounded against inflation of hidden reasoning tokens — the price of fairness is a √(1+Θ) manipulation gap.
Two things stand out for anyone shipping an agent that pays, or a service that gets paid.
First, the attack surface is now formal. Before this paper, the security conversation was a list of anecdotes. Now there's a taxonomy — five invariants, four flaw classes, and a reproducible test harness — so "is my integration safe?" has a concrete checklist instead of a vibe. If you can't answer "is my authorization bound to the resource, is my nonce consumed exactly once, do I lock funds before executing, and do I fail closed on the settlement path," you have work to do.
Second, the leakage is merchant-side. The headline crypto-safety story is usually about the payer getting drained. Here, three of the four classes (F2, F3, F4) are about the service provider streaming output it never gets paid for — up to 100% of it. The agent-payment rails are young enough that a provider can be silently subsidizing free riders and not know it.
This is also why we built the audit vertical we did. We audited our own facilitator against the earlier EPFL/Zhejiang study and fixed a confirmed free-shopping bug in production — the same discipline this paper now formalizes. And the deeper point from our verification-gap write-up still holds: the rails moving the money are not the layer that tells an agent the thing it bought is real. Security and verification are the unsolved layer, and they're now measurable.
If you're running an x402 endpoint and want to check your own contract surface, our contract-audit tool does a $2 static scan over ten deterministic vulnerability patterns, or a $20 AI deep audit across Solidity, Rust, and Move — payable per call in USDC, no API keys. It won't replace the protocol-level checks above, but it's a fast first pass on the Solidity half of the stack while the payment-path half gets its own review.