x402 Fixed Three Bugs That Let an API Drain an AI Agent's Wallet. No Advisory Was Filed, So Every Checker Said Allow. Ours Did Too, Until Today.
If your agents pay for APIs with x402, upgrade the @x402 packages to 2.23.0 or later today (2.28.0 is current), and do not turn the new spending limits off. Then check your lockfile, because nothing else will tell you to: the bugs below were fixed in August without a security advisory, so npm audit, OSV and, until this morning, our own package check all reported the vulnerable versions as clean.
What the bugs were
x402 lets an AI agent pay for an API call on the spot: the server answers HTTP 402 with a price, the agent signs a payment, and the call goes through. Coinbase built it and handed it to the x402 Foundation at the Linux Foundation this year. V12, a security firm, reviewed the code and reported 25 findings on August 12. Three were critical.
No spending limit by default. The documented client took the first payment option a server offered and set no cap. A hostile API could ask for the wallet's entire balance of a supported token, and an agent with an automatic signer would sign it. This is token theft in its plainest form: the agent's own budget, spent by whoever it was talking to.
A token approval accepted as a payment. The TypeScript Solana facilitator checked the token program but not the instruction type. An approval moves no money and differs from a transfer by one byte. In V12's local test the facilitator accepted it as payment, so a merchant could deliver a paid resource and receive nothing.
A login signature that works somewhere else. The Sign-In-With-X client signed login messages without checking that the site named in the message was the site it had contacted. A malicious server could fetch a login challenge from another site, have your agent sign it, and log in there as your agent's wallet.
The fixes shipped between August 18 and 20 in the TypeScript, Python and Go clients. The new default caps each payment at one dollar and accepts only recognized dollar stablecoins such as USDC. Neither V12 nor the foundation has reported attacks using these bugs.
Why your tools say you are fine
A vulnerability scanner can only flag what an advisory describes. The x402 Foundation published no advisory, no CVE and no GHSA for these three bugs, and its changelogs list the fixes without calling them security fixes. As of October 23, npm audit returned nothing for the last TypeScript releases before the fix, and PyPI listed no vulnerabilities for the matching Python release.
Our check-package tool had the same blind spot. It is the pre-install check we offer agents and CI pipelines, and it judges known-vulnerable versions by OSV, the open vulnerability database. This morning we asked it about @x402/svm 2.22.0, the last Solana release without the fix. It answered allow, with zero known vulnerabilities. So did @x402/fetch 2.22.0. The answer was accurate about the database and wrong about the package.
What we changed
We added a short, cited list of security fixes shipped without an advisory. For a version below the fix, check-package now answers review, not allow, names the fixed version, links the primary source, and says plainly that npm audit and OSV will not flag it. We checked it live: @x402/svm 2.22.0 now returns review, and 2.28.0 returns allow. It never returns block, because an old version of a reputable package is an upgrade decision, not malware.
The list covers @x402/svm, @x402/core, @x402/fetch, @x402/axios and @x402/extensions on npm. We have not yet confirmed the exact first fixed version of the Python package, so it is not on the list; if you use Python, upgrade to 2.25.0, the current release. An entry comes off the list once OSV carries a real advisory for it.
What to do
Upgrade @x402/fetch and @x402/axios to 2.23.0 or later. If you run a Solana facilitator, upgrade @x402/svm. If you use Sign-In-With-X, upgrade @x402/extensions.
Leave the spending limits on. Do not set spendControls to false unless you mean it.
If you cannot upgrade yet, register a payment policy that drops any option above a fixed amount (registerPolicy in TypeScript and Go, register_policy in Python; the SDK includes a ready-made max_amount policy).
Set a budget per payment and in total, and limit which tokens, networks and recipients your agent will pay.
Credit to V12 for the research and the clear write-up, and to The Hacker News for checking the published packages.
If this was useful, or if it wasn't, the rating widget below takes ten seconds and is the only way we know.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=x402-fixed-three-bugs-that-let-an-api-drain-an-ai-agent-s-wallet-no-advisory-was-filed-so-every-ch
Comments