x402 Security Risks: What the Published Research and Open Issues Show (October 2026)

x402 extends HTTP 402 ("Payment Required"). A resource server answers a request with payment requirements, the client returns a signed payment payload, and a facilitator verifies the payload and settles it on-chain^[8]. Wang et al. put the consequence this way: facilitators "serve as a shared payment infrastructure for many independent merchants. This centralizes trust and validation in one component, so a single flaw can affect many services"^[1].

Qinying Wang, Yong Yang, Yuan Chen, Shouling Ji and Mathias Payer, "When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments", arXiv:2607.19545, submitted 21 July 2026. The arXiv record lists USENIX Security 2026 as its journal reference^[1]. What the paper reports:

• Eight security rules for facilitators.SR1 to SR4 cover authorization: proofs must match the server's requirements, payer authorization and balance must be valid, freshness must be enforced, and success must not be reported unless the payment condition holds. SR5 to SR8 cover execution: reject payments that can't settle or are economically meaningless, bound sponsor-paid costs, re-check time- and state-dependent conditions before settlement, and restrict on-chain execution to well-defined payment semantics.
• Every facilitator tested broke at least one rule.The 15 facilitators are "collectively used by over 60K sellers and 360K buyers" and, per the authors, account for 99% of x402 transactions. The authors report 49 rule violations, which they translate into 31 previously unknown vulnerabilities. Every rule was broken by at least one platform.
• Four attack classes:Free Shopping, Asset Theft, Service Denial and Gas Abuse. The authors rank sponsor-paid cost amplification and free shopping as the most common practical risks. Asset theft is rarer but has the highest impact. They attribute free shopping to "release-after-verify" behavior in merchants and SDKs: the resource is delivered after verification but before settlement succeeds.
• Disclosure.The affected parties "acknowledged the issues and adopted mitigations, including changes by Coinbase."
• On-chain measurement.Across more than 119 million Base and Solana transactions, x402-related settlement attempts had "burned over $202K in gas and fees, including $5.8K from reverting submissions alone". The authors treat this "as risk evidence rather than attack attribution."

The x402 TypeScript packages let extensions run hooks before and after verification and settlement. Two open threads in the x402 Foundation repository concern what happens when a hook throws an error.

Issue #3689 (opened October 4, 2026). In the @x402/core resource server, when a hook throws in beforeVerify or beforeSettle, "the exception is logged and the loop continues as if the hook had passed. The payment then verifies and settles normally." In beforeSettle, only SettleError is rethrown. The reporter reproduced this against main at commit 751590a(October 2, 2026), using the package's own unit-test mocks. A throwing onBeforeVerify hook still returns isValid: true. The issue proposes three options. A throw in a gate phase could count as an abort. Extensions could declare that their gates fail closed. Or the current behavior could be documented. The reporter prefers the first^[5]. When we checked on October 4, the issue had no comments.

Pull request #3151 (opened August 14, 2026; not merged). This PR addresses issue #1826, which reported that a throwing afterSettle hook made a payment that had already settled on-chain look like a failure^[7]. The PR wraps all six facilitator hook loops so that a throwing hook is logged and skipped, "mirroring the resource server's pattern." The intentional beforeSettle abort is still honored. Under the PR, a throwing beforeVerify or beforeSettlehook "does not stop later hooks"^[6].

Our reading.The two threads aren't in conflict. Isolating errors in after-hooks keeps a settled payment from being reported as failed. Applying the same "log and skip" rule to before-hooks means a gate that couldn't finish its check lets the payment through. One approach that fits both: isolate advisory hooks, and fail closed on gate hooks. This is a description of open threads, not a statement about any deployment.

1. Decide when you release the resource. If you can't tolerate free shopping, release only after settlement is confirmed, or cap the value you'll deliver before then.
2. Don't treat the facilitator's answer as final. Re-check the amount, asset, payee and network against your own payment requirements.
3. Until upstream behavior changes, wrap every gate-phase extension hook so that any error returns an abort. Add a test that throws inside the hook and confirms the payment is refused.
4. Re-validate time- and state-dependent conditions just before settlement, not only at verification.
5. If you operate a facilitator, put limits on sponsor-paid gas and fees, and restrict settlement to well-defined payment calls.
6. Bind each payment to one resource and one use. Reject replayed or substituted authorizations.
7. For upto-style allowances, reserve and decrement the allowance atomically instead of checking a snapshot.
8. Record verify and settle outcomes separately in your audit log, so a hook failure after settlement can't hide a completed payment.
9. Pin SDK versions and track the issues above. Re-test hook behavior on every upgrade.

For limits on what an agent may spend, see AI agent spending limits. The Agent Payment Risk Index^[9] lists these papers as research findings, not production losses.