The default x402 SDK client signed payments with no spending cap, draining AI agents’ balances
On October 22, 2026, V12 revealed that the default client of the x402 payment SDKs signed payments with no spending limit, letting a malicious API drain an AI agent’s balance in a single request. The August 18 fixes exist, but they are not flagged as security in npm or PyPI: upgrade and set your own spending caps.
October 22, 2026. Security firm V12 publishes an analysis of 25 flaws in the x402 payment SDKs, including three critical ones described in detail. August 18, 2026. The fixes for all three are already in the releases shipped by the x402 Foundation. October 23, 2026. Neither npm nor PyPI flags a security update, and no exploitation is documented. Why it matters: an AI agent that signs its own payments could sign away its full balance of a supported token, without its developer getting any warning.
x402 lets an API call pay for itself inside the request
x402 is an open standard that lets software — above all AI agents — pay for an API call within the web request itself, with no human approving each payment. The name comes from the HTTP 402 Payment Required status code. A server that wants payment answers with that code and lists its options: an amount, a token and a recipient. The client picks one, signs a payment and sends the request again.
The standard began at Coinbase, which handed it this year to the x402 Foundation, a Linux Foundation project whose members include Visa and Mastercard. Coinbase holds the most senior seat on the foundation’s technical steering committee. This is not code running in a corner: it underpins agent payments that financial institutions are watching closely.
Three critical flaws, one signature: the insecure default
The first critical flaw was in the default client. Before the August 18 releases, that client set no spending limit. It took the first option on the server’s list. A hostile API could therefore turn a routine data request into a request for the wallet’s full balance of a supported token — an earlier small payment being enough to reveal the wallet address so the server could look up the balance first. With an automatic signer and no payment policy set by the app, the client would sign the requested amount. For a token that supports signed transfers, the attacker only had to submit the signed payment and collect.
The second flaw hit the Solana facilitator, the service that checks each payment and submits it to the blockchain. The TypeScript code read a payment calling an allowed token program as a transfer without checking the instruction type. A token approval — which lets another account spend later but moves nothing itself — differs from a transfer only in its first byte. In V12’s local test, the facilitator accepted such an approval as a valid payment, a “complete payment bypass”: the merchant delivered a paid resource while receiving no tokens, and the facilitator paid the transaction fee each time. The Python and Go SDKs already checked the instruction type; the August 18 releases added the same check to the TypeScript code.
The third flaw concerned Sign-In-With-X (SIWx), the sign-in extension that lets an agent prove an earlier payment by signing a short message with its wallet. On Ethereum, the message names the website, the wallet address and a one-time code. The automated client signed these messages without verifying that the named website was the one it had contacted. A malicious server could fetch a fresh login message from another site, pass it to the agent, and reuse the signature to log in to that site as the agent’s wallet.
The fixes exist, but the toolchain’s silence is the real problem
All three critical flaws are already fixed in the August 18 releases: the TypeScript, Python and Go clients now cap each payment at $1 and allow only recognized dollar stablecoins such as USDC; the TypeScript facilitator checks the instruction type; and the SIWx client verifies the named website. V12 found the flaws only by reading the code and running local tests, and neither V12 nor the x402 Foundation has reported any real attack.
The problem is elsewhere. The foundation published no security advisory for the three flaws, and its changelogs list the fixes without calling them security fixes. As of October 23, npm audit returned no advisories for the last TypeScript releases before the fixes, and PyPI listed no vulnerabilities for the last Python release before them. A developer who relies on those checks gets no signal to upgrade.
That is the heart of the matter for an SRE deploying autonomous agents: when security depends on a payment SDK, trusting npm audit or PyPI advisories is no longer enough. You have to read the changelogs — and above all define your own spending policy rather than inheriting the client’s default.
Verdict
If you build agents that pay through x402, upgrade now. On the TypeScript side, every @x402/svm release from 2.0.0 to 2.22.0 omits the instruction-type check: move to 2.23.0 or later. On the client side, the August 18 releases add spending caps — but do not rely on the default alone. Set an explicit spending cap and an allowlist of tokens in your application, because a “no-limit” client remains the historical default and the first thing a hostile API will try to exploit.
If you are a merchant relying on the Solana facilitator, verify you no longer accept token approvals as payment, or you will deliver paid resources while collecting nothing. And for the whole chain: do not treat the absence of an npm audit or PyPI alert as proof of safety — all three critical flaws are fixed, but none was ever flagged as security. The lesson goes beyond x402: as agents gain the ability to spend, the risk surface shifts from “who can run code” to “who can sign a payment”, and the guardrails must be set by the developer, not inherited from the SDK.