x402 SDK Vulnerabilities
Imagine an autonomous AI agent tasked with purchasing data, only to have a malicious server demand the wallet's entire balance instead of the standard fee. This scenario is exactly what researchers at V12 uncovered when analyzing the x402 SDKs, because the default client set no spending limit until August releases added one, exposing automated agents to critical x402 SDK vulnerabilities that could drain their funds without a single human approval.
The missing limit is just one of 25 flaws V12 found in the x402 code, and it is one of three that the firm rated as critical. The x402 Foundation, which maintains the SDKs, had already fixed all three critical flaws in the August 18 releases, but the fixes were pushed without any public security advisories.
The Missing Spending Limit in the Default Client
To understand the flaw, you have to look at how x402 operates, because it is an open standard that lets software, including AI agents, pay for an API call within the web request itself, without requiring a person to approve each payment.
A server that wants payment answers with the HTTP status code 402 Payment Required and lists its payment options, each with an amount, a token, and a recipient, so the client picks one, signs a payment, and sends the request again. The default client took the first option on the list, and before the fix, it set no limit on the amount.
A hostile API could use that to turn a routine data request into a request for the wallet's full balance of a supported token, V12 said, and an earlier small payment could reveal the wallet address, so the server could look up the balance first, and with an automatic signer and no payment policy set by the app, the client could sign a payment for that amount.
For a token that supports signed transfers, the attacker could then submit the signed payment and collect the funds, which is why the August 18 releases added spend controls to the TypeScript, Python, and Go clients, capping each payment at $1 and allowing only US dollar stablecoins the SDK recognizes, such as USDC.
The Solana Payment Bypass
In x402, a merchant's server relies on a facilitator to check each payment and submit it to the blockchain, and on Solana, the facilitator also pays the transaction fee.
The TypeScript facilitator code for Solana checked that a payment called an allowed token program, then read it as a transfer without checking the instruction type, because 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, meaning a merchant relying on the facilitator could deliver a paid resource while receiving no tokens, and V12 called it 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 same check to the TypeScript code.
Cross-Site Login Signatures
x402 also has a sign-in extension called Sign-In-With-X (SIWx), which lets an agent log in by signing a short message with its wallet, for example to prove an earlier payment instead of paying again, and 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 website named in them was the one it had contacted, so a malicious server could get 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. That would work wherever the other site accepted the relayed message, and the attacker would get whatever access the login allowed.
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.
The Silent Patch and Scanner Blind Spot
The x402 Foundation has 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, The Hacker News found. A developer who relies on those automated checks gets no warning to upgrade, which is a critical blind spot for CI/CD pipelines that rely on automated dependency scanning.
Coinbase created x402 and handed it to the x402 Foundation this year, a Linux Foundation project whose members include Visa and Mastercard.
How to Patch and Protect Your AI Agents
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 the core, SVM, extensions, fetch, and axios packages, v2.28.0 for the Go module, and 2.25.0 for the Python package.
To secure your agents, take these steps:
- Update your packages: In TypeScript, update @x402/fetch or @x402/axios to 2.23.0 or later to get the spending fix, and apps using SIWx need @x402/extensions 2.23.0 or later, while facilitators checking Solana payments need @x402/svm 2.23.0 or later.
- Check your spend controls: After the upgrade, existing clients are capped at $1 per payment and limited to recognized stablecoins unless the app sets its own spend controls, so ensure your apps do not pass spendControls: false, which turns all of these controls off.
- Use payment policies: Teams that cannot upgrade yet can register a payment policy that drops any option above a set amount, and the older clients support this with registerPolicy in TypeScript and Go, and register_policy in Python, which also has a ready-made max_amount policy.
- Verify login messages: V12 advises clients to check that a SIWx login message identifies the site they contacted before signing, to set budgets for each payment and in total, and to limit which tokens, networks, and recipients they will pay.
FAQ
What is x402?
x402 is an open standard, originally created by Coinbase, that lets software and AI agents pay for API calls within the web request itself using HTTP status code 402 Payment Required.
What is the x402 spending limit flaw?
Before the August 18 patch, the default client set no spending limit and took the first payment option a server offered, so a malicious API could request the wallet's full balance of a supported token, and the client would sign the payment.
Does this affect all x402 SDKs?
The spending limit and SIWx flaws affected the TypeScript, Python, and Go clients, while the Solana payment bypass only affected the TypeScript facilitator code.
Why didn't npm audit or PyPI warn me about this?
The x402 Foundation did not publish a security advisory or assign CVEs for these flaws, and the changelogs simply listed them as general fixes, so automated scanning tools had nothing to flag.
How do I check if my AI agent is vulnerable?
Check your dependency versions. If you are running @x402/fetch or @x402/axios below 2.23.0, @x402/svm below 2.23.0, or the older Python/Go SDKs, you are exposed.
