x402 SDK Flaw Let Malicious APIs Request an AI Agent's Entire Token Balance

AI agents using the x402 SDKs could be made to sign away their full balance of a supported token if a malicious API asked for it, security firm V12 reported on October 22.

The problem sat in the SDKs' default client, which applied no spending limit until releases on August 18 introduced one. Only agents that signed payments automatically, in apps that set no limits of their own, were exposed.

The missing limit was one of 25 flaws V12 found in the x402 code and one of three it rated critical. The x402 Foundation, which maintains the SDKs, had already fixed all three critical issues in the August 18 releases.

Another of the three let a facilitator - the service that validates x402 payments - accept a Solana transaction that moved no tokens as a valid payment. Only the TypeScript SDK had this flaw. The third let a malicious server trick an agent into signing a login message for a different website.

V12 found the flaws by reviewing code and running local tests. Neither V12 nor the foundation has publicly reported any attacks exploiting them.

No security advisory has been published for the three flaws, and the changelogs list the fixes without labeling 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, The Hacker News found - meaning developers who rely on those checks get no warning to upgrade.

Coinbase created x402 and handed it to the x402 Foundation this year, a Linux Foundation project whose members include Visa and Mastercard. Coinbase holds the most senior seat on the foundation's technical steering committee.

x402 is an open standard that lets software, including AI agents, pay for an API call within the web request itself, without a person approving each payment. A server wanting payment replies with HTTP status 402 Payment Required and lists its options, each with an amount, token and recipient; the client picks one, signs, and resends the request.

The default client took the first option on the list and, before the fix, set no cap on the amount. A hostile API could turn a routine data request into a demand for the wallet's full balance of a supported token, V12 said. An earlier small payment could reveal the wallet address, letting the server look up the balance first. With an automatic signer and no payment policy from the app, the client could sign for that amount, and for a token supporting signed transfers, the attacker could submit the payment and collect the funds.

The August 18 releases added spend controls to the TypeScript, Python and Go clients, capping each payment at $1 by default and allowing only recognized US dollar stablecoins such as USDC.

On Solana, the TypeScript facilitator code read a payment as a transfer without checking the instruction type. A token approval, which lets another account spend tokens later but moves none 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; the test did not send a live transaction. A merchant relying on the facilitator could deliver a paid resource while receiving no tokens - what V12 called "a complete payment bypass." The attacker needed a token account but no balance, and the facilitator paid the transaction fee each time. The Python and Go SDKs already checked the instruction type, and the August 18 releases added the check to TypeScript.

The SIWx sign-in extension lets an agent log in by signing a short message with its wallet. The automated client signed these messages without verifying that the website named in them was the one it had contacted. A malicious server could obtain a fresh login message from another site, pass it to the agent, and use the signature to log in to that site as the agent's wallet, V12 said. The August 18 releases make the TypeScript, Python and Go clients refuse to sign unless the site in the message matches the site that sent the 402 response, and the SIWx specification was changed to require the same.

Upgrading to the latest releases also brings later fixes, including one for a separate payment bypass in @x402/core 2.27.0 in September. As of October 23, the latest versions are 2.28.0 for @x402/core, @x402/svm, @x402/extensions, @x402/fetch and @x402/axios, v2.28.0 for the Go module and 2.25.0 for the Python package.

Teams that cannot upgrade yet can register a payment policy that drops any option above a set amount - registerPolicy in TypeScript and Go, register_policy in Python, which also offers a ready-made max_amount policy. V12 advises clients to confirm a SIWx login message names the site they contacted before signing, to set per-payment and total budgets, and to limit which tokens, networks and recipients they will pay.

Source: The Hackers News