A payment protocol just taught agents to drain their own wallets

Agent frameworks have spent 2026 learning the obvious lesson that the content an agent reads from the network is attacker-controlled. Last week the lesson arrived at the payment layer. V12 disclosed 25 flaws in the x402 agent payment SDK, three of them critical, including one where the default client would sign a payment for the entire wallet balance if the server asked for it. The fixes shipped quietly in August. There are no CVEs, no npm or PyPI advisories, no security changelog entry. Developers using the pre-fix SDK had no particular reason to know they had been exposed.

What x402 is

x402 is an HTTP 402-based micropayment protocol originated at Coinbase and now stewarded by the x402 Foundation, a Linux Foundation project. It gives autonomous agents a way to pay small amounts for API calls: the server returns HTTP 402 with a quoted amount, the client signs a payment, the request succeeds. Default clients ship for TypeScript, Python, and Go. The design assumes the agent cannot stop in the middle of a task to ask a human for permission on every $0.0001 — so by default, it doesn't.

The three critical flaws V12 described

No per-payment spending limit in the default client. Before version 2.23.0, @x402/fetch and @x402/axios picked the first payment option in a 402 response and signed it. The amount was whatever the server asked for. A malicious API could request the wallet's full balance of a supported token. A small earlier payment is enough to reveal the wallet address, so the server can look up the balance first and then quote exactly that number. For tokens with signed transfers, the attacker submits the signed payment and the money is gone.

A Solana facilitator accepted an approval as payment. The TypeScript Solana facilitator in @x402/svm 2.0.0 through 2.22.0 checked that a transaction called an allowed token program, but did not check the instruction type. It therefore accepted a token-approval instruction, which moves zero tokens, as a valid payment. V12 called this "a complete payment bypass". The attacker needed a token account with no balance; the facilitator paid the transaction fee itself.

Relayed SIWx login signatures. The automated client signed Sign-In With X login messages without checking that the named site matched the site it was contacting. A malicious server could obtain a login message from a different site and relay it to the agent. The attacker then logs in to that other site as the agent's wallet. Any TypeScript, Python, or Go client before the August releases was in scope.

What the fix looks like

The x402 Foundation shipped the fixes on August 18, 2026. @x402/svm, @x402/fetch, @x402/axios, and @x402/extensions all moved to 2.23.0. The default client now caps payments at $1 per request and limits them to recognized USD stablecoins. SIWx clients refuse to sign when the message's named site does not match the site that served it. Teams that cannot upgrade can register a payment policy that drops options above a set amount with registerPolicy in TypeScript and Go or register_policy in Python.

The changelogs for 2.23.0 did not call these security fixes. No CVE IDs were assigned. There is no x402 Foundation security advisory. npm audit and PyPI show no advisories against the pre-fix releases. Teams that pinned old versions have no way to find out from their dependency manager that anything changed.

Why this is a different problem from the usual SDK bug

Three things make the x402 story worth sitting with.

The attacker speaks the protocol. The agent is doing exactly what the protocol tells it to do: receive a quote, sign a payment. The "vulnerability" is that the default client treats the server's quote as authoritative. Any defender posture that assumes the SDK will refuse unreasonable requests is a posture that trusts the attacker-side of the exchange to be reasonable.

Silent fixes are becoming the industry pattern. The x402 Foundation shipped the fix without a security changelog. Anthropic's OpenCode team declined to request a CVE for a 9.8-rated MCP OAuth flaw two days ago, framing malicious MCP servers as "outside our trust boundary." OpenAI classed a working ChatGPT GitHub Connector prompt-injection chain as "out of scope" the same week. Three independent AI/agent-infrastructure vendors chose vendor-scope-exclusion over coordinated disclosure for critical boundary primitives inside a seven-day window. Enterprise defenders cannot build their patch cadence against a signal the vendor isn't emitting.

The budget boundary is now a runtime observable, not a code property. The spending cap only works if the agent's code is on the fixed version. Any older client in a production stack, any copy running inside a sub-agent, any fork that disabled spendControls to clear a hot path — all of them signed payments for whatever the server quoted. The question for a defender is not "did we upgrade?" but "what is the agent allowed to spend in this session, and does the outbound signature match?"

The takeaway

Agent payment protocols are not an exotic surface. They are an attack surface. x402 is the first widely-adopted agent payment layer where three independent critical flaws have been publicly described at per-SDK, per-language resolution, in a Linux Foundation project, with no CVEs and no advisories to drive remediation. Enterprise defenders deploying agents against partner APIs need their own budget boundary. The payment that leaves the wallet is the observable; the agent's belief about what the server was asking for is not.

SPR{K3 is a security research operation that pairs offensive vulnerability research with runtime behavioral defense. Defend is our runtime agent. To talk about a deployment, reach us at support@sprk3.com.