Six Attacks on x402 Payments, and the Guard for Each
x402 attacks run in two directions. Against the buyer: a changed price in the payment terms, a duplicate charge, a lookalike seller, and prompt injection that talks the agent into paying again. Against the seller: content obtained without payment, and one payment unlocking many resources. Each has a guard in code on the side being attacked.
The talk, and the flow it attacks
"Your Agent Just Paid for Nothing: 6 Attacks on x402 Payments" is a talk by Ishween Kaur of SoFi, published on the AI Engineer channel on October 30, 2026. Its description says she walks through six of the twenty ways she broke the protocol in a safe test environment: price changes in the payment header, paying twice, getting data for free, one payment unlocking many pages, lookalike sellers, and prompt injection that talks an agent into paying again, showing the guard that stopped each one. This page uses that taxonomy as its structure. The mechanisms and guards below are written from the protocol and public disclosures, not transcribed from the talk. None of the six has been reported in the wild: they are test-environment demonstrations, disclosed SDK bugs, or results from published research.
The flow: the client requests a resource, the server answers 402 with payment requirements (amount, asset, network, recipient), the client signs a payment payload and retries with it attached, the server has a facilitator verify and settle it, and then serves the resource. Every attack below breaks one link between paying and receiving. The useful question for each is which side loses money, because that side has to own the guard.
Attacks that cost the buyer
The first four leave the agent having paid for something it did not want, did not get, or paid for already.
1. Price manipulation
The amount in the payment requirements is written by the server. A hostile server, a compromised one, or an intermediary on a weak link can raise it, and a client that signs whatever is asked pays it. A spending cap does not help when the inflated price still fits beneath it. The Cloud Security Alliance's note on the SDK flaws describes the related weakness: there was no default spending limit, and the default client took the first option the server offered, so a hostile server could ask for the balance. A $1 default cap arrived in 2.23.0 on August 18, 2026. In the talk itself, Kaur settled 50 cents against a 5-cent listing on Base Sepolia. Guard: keep an expected price per resource in operator config, compare before signing, and abort on mismatch.
2. Paying twice
In the talk this runs against the seller: one payment identifier presented on two pages, with state not shared between them, settles once and delivers twice. The buyer-side mirror, which is our own extension of the same fault, is a timeout after payment, a retry loop that requests from scratch, or a server answering a paid retry with a fresh 402, each producing a second charge for one delivery. Guard, both directions: give each logical purchase an idempotency key, hold payment state in storage shared by every process that can serve the resource, and on a repeated 402 check whether an existing payment already covers the request before creating another.
3. Lookalike sellers
In the talk, an impostor listed itself in the discovery catalog under its own name, domain and wallet, undercut the real seller, and a cost-optimising agent chose it. Published research reports the same shape through Sybil listings. Guard: keep allow, block and probation lists for sellers rather than trusting discovery ranking, pin the recipient per service from a verified source, compare the full address, and require explicit approval for the first payment to any new recipient. Pinning alone does not help an agent that is free to discover new sellers.
4. Prompt injection that pays again
Content the agent reads, including a paid response, can contain text instructing it to buy again, buy more, or pay a different party. If the model decides when and whom to pay, that text competes with its instructions. Guard: the model proposes, code decides. The payment tool should accept a resource identifier rather than an arbitrary address and amount, and budgets and allowlists should live outside the model's context.
Attacks that cost the seller
The other two leave the seller having served something it was not paid for.
5. Free shopping
The seller delivers without being paid. Common causes: serving before verification completes, letting a CDN or shared cache store a paid response and hand it to the next caller, or trusting a verification that checked the wrong thing. The last case is real. V12 disclosed in October 2026 that the x402 TypeScript Solana facilitator accepted an approval instruction, which moves no tokens, as a transfer, because the two differ only in their first byte. The fix shipped in @x402/svm 2.23.0. Guard: verify before serving, send Cache-Control: no-store on paid bodies, pin facilitator versions, and for valuable items confirm settlement onchain before delivery.
6. One payment, many pages
If a payment proves only that the buyer paid something, it can be presented again for other resources or other routes. Published research found that no audited SDK bound a payment to the resource it was issued for, so a payment for one route could be replayed on others. Separately, an encoded-path bypass in @x402/core was fixed in 2.27.0 on September 22, 2026. Guard: bind each payment to the resource and price it was issued for, consume each payment identifier once, and check entitlement per route.
The trust delegated to the facilitator
Both sides lean on the facilitator. The seller trusts its verdict that a payload is a valid payment; the buyer trusts it to settle exactly what was signed. That is a reasonable division of labour and also a single dependency whose bugs land on everyone using it, as the Solana case showed.
Treat it like any payment dependency: pin versions, read the release notes, and keep an independent check for high-value flows, such as confirming the transfer onchain to your own address before releasing goods. Running your own facilitator moves the trust rather than removing it; you then own the verification logic and its updates.
Rolling it out
Start on a testnet such as Base Sepolia with every guard enabled and logging on. Log each 402 challenge with its amount and recipient, and alert when either changes for a known service. Run the six attacks against your own client and server before production; each is cheap to simulate with a test server that misbehaves on purpose. Then go live with small per-payment caps, a short list of allowed sellers, and a session key whose period budget bounds the worst case while the logs build a baseline.
Frequently asked questions
- What are the six x402 attacks in Ishween Kaur's talk?
- According to the talk's description and chapters, published by AI Engineer on October 30, 2026: price manipulation in the payment header, paying twice, free shopping (getting data without paying), one payment unlocking many pages, lookalike sellers, and prompt injection that talks an agent into paying again. She describes them as six of twenty ways she broke x402 in a test environment.
- How can an AI agent pay for nothing over x402?
- By signing terms the server controls without checking them. A raised price, a recipient that only resembles the real one, a retry that creates a second payment, or injected text prompting another purchase all lead to paying without matching value. The guards are an expected-price check, pinned recipients, idempotency keys, and payment decisions made in code rather than by the model.
- How does an x402 seller end up serving content for free?
- By delivering before verification completes, letting a shared cache store paid responses, accepting a payment that is not tied to the specific resource, or trusting a facilitator verdict that checked the wrong thing. Bind payments to resources, consume each once, send Cache-Control: no-store, pin facilitator versions, and confirm settlement onchain for valuable items.
- Does a spending cap stop these attacks?
- Only the most blatant ones. A cap blocks a single charge above it, but a moderately inflated price, a payment to a lookalike address, or a second payment injected by a prompt can each fit underneath. Caps bound the damage; validation of price, recipient, and request binding is what prevents the attack in the first place.