Researchers at V12 have detailed three critical weaknesses in x402, an open standard that lets AI agents pay for web services on their own, including a default client that could sign away an entire token balance on request. The fixes shipped in August with no advisory or CVE, so dependency scanners still give vulnerable builds a clean bill of health.
What happened
On 22 October 2026, security firm V12 published research into x402, a protocol that builds payment into an ordinary HTTP exchange so that software, and autonomous AI agents in particular, can buy data or API calls without a human approving each transaction. V12 found 25 vulnerabilities and rated three critical. It reported the critical and 13 high-severity issues to the maintainers on 12 August and says the critical ones were resolved by 20 August; The Hacker News dates the relevant SDK releases to 18 August.
x402 was created by Coinbase and is now run by the x402 Foundation under the Linux Foundation, with Visa and Mastercard among its members.
The awkward part is how quietly the bugs were closed. According to The Hacker News, the foundation issued no security advisory and its changelogs do not describe the changes as security fixes. As of 23 October, npm audit flagged nothing in the last vulnerable TypeScript releases and PyPI showed no known issues for the last affected Python package, a gap ScriptMasterLabs also highlighted. Neither V12 nor the foundation has reported exploitation in the wild, and only the three critical findings have been described publicly.
The technical picture
A server that wants paying answers a request with HTTP status 402 Payment Required and lists acceptable options covering price, token, chain and payee. The client signs, retries, and a third party called a facilitator verifies the payment and submits it on chain. Each critical flaw broke a different link in that chain of trust.
No spending ceiling. The documented default client took the first option a server offered and enforced no per-payment or overall budget. A malicious API could therefore convert an ordinary lookup into a demand for everything the wallet held in a supported token, and an agent set to sign automatically, with no application-level limits, would oblige. V12 added that a tiny first charge could expose the wallet address, letting an attacker look up the balance beforehand. The August releases cap each payment at $1 by default and accept only recognised US dollar stablecoins such as USDC.
An approval counted as a payment. On Solana, the TypeScript facilitator confirmed a transaction called a permitted token program but never checked which instruction it contained. A token approval, which grants spending rights but moves no money, differs from a transfer by a single byte, so it could pass as payment. V12 described the result as “a complete payment bypass” in local testing: the merchant delivers, receives nothing, and the facilitator pays the fee. Python and Go already had the check. According to The Hacker News, every @x402/svm release from 2.0.0 to 2.22.0 is affected and 2.23.0 onwards is fixed.
Logins signed for the wrong site. The Sign-In-With-X extension lets an agent authenticate with its wallet. The automatic wrapper signed whatever login message a server supplied without confirming that the site named in it was the one actually contacted. A malicious server could obtain a fresh challenge from another service, have the agent sign it and replay the signature to take over the agent’s session there. All three SDKs now refuse to sign on a mismatch, and the specification makes that mandatory.
Why it matters for UK organisations
UK teams experimenting with agentic payments typically assemble them from open-source components rather than writing payment logic themselves. Any UK developer who pulled a pre-August x402 release into an agent and has not upgraded may be running a client that signs whatever a server asks. Pinned lockfiles make it worse: a vulnerable version can sit there indefinitely because software composition tools have nothing to match against.
There is a regulatory dimension too. The FCA published final rules for the UK cryptoasset regime on 30 June 2026; its authorisation gateway opened on 30 September and full commencement is pencilled in for 25 October 2027. Firms issuing qualifying stablecoins, safeguarding cryptoassets or arranging deals will need governance, systems and controls closer to those of traditional regulated firms, operational resilience included. A business that lets an agent hold and spend stablecoins, or that runs a facilitator for others, should expect to be asked how spending is bounded and how third-party code is vetted.
Silent patching is also a supply chain problem well beyond crypto: if a maintainer treats a fix as routine, your vulnerability management process never hears about it.
Expert view
What strikes me is how ordinary these bugs are. None needs a novel attack on a language model. The spending flaw is excessive trust in server-supplied input, the Solana issue is a missing type check, and the login relay is the origin-binding mistake we have found in single sign-on flows for years. The difference is the consequence: when the client is an autonomous agent with a funded wallet, a validation slip becomes direct financial loss.
Teams building agents tend to focus on prompt injection and give far less attention to the plumbing the agent calls. An agent with signing authority is a privileged service account with a payment card attached, and deserves the same least-privilege thinking, hard limits and monitoring.
The disclosure handling deserves criticism. Fixing critical bugs within days is good practice; not telling anyone they were security fixes is not. When we test build pipelines, dependency audit output is often the only signal developers act on, and without an advisory or CVE it stays green. Foundations courting financial institutions must publish advisories routinely.
What to do now
- Find every use of x402. Search repositories, lockfiles and container images for @x402 packages, the Python package and the Go module. Do not rely on npm audit or PyPI.
- Upgrade. Clients need @x402/fetch or @x402/axios 2.23.0 or later, Sign-In-With-X users @x402/extensions 2.23.0 or later, and Solana facilitators @x402/svm 2.23.0 or later. This is Cyber Essentials security update management.
- Set explicit budgets. Do not lean on the $1 default. Configure per-payment and total limits and restrict tokens, networks and payees. Check nobody has set spendControls: false. If you cannot upgrade yet, register a policy that rejects options above a fixed amount.
- Apply least privilege to agent wallets. Fund them only for the task, keep them apart from treasury funds and treat signing keys as privileged credentials, in line with Cyber Essentials user access control and secure configuration.
- Reconcile facilitator records. If you verified Solana payments with an affected TypeScript facilitator, compare resources delivered against funds actually received.
- Watch agent spending. Alert on unusual amounts, new payees and sign-in requests for unexpected domains.
Bottom line
x402 shows that the riskiest part of an AI agent may be the ordinary code it trusts with money. The bugs are fixed, but only for those who upgrade, and without advisories many will not know they need to. If your agents can pay for anything, check versions, set hard limits today and read upstream changelogs as closely as advisory feeds.
Sources
- V12: 25 Vulnerabilities in the x402 Protocol: Inside Three Critical Findings
- The Hacker News: Critical x402 SDK Flaw Could Let Malicious APIs Drain AI Agents’ Token Balances
- ScriptMasterLabs (DEV Community): Can a Malicious API Drain an AI Agent’s Wallet With x402?
- Lewis Silkin: FCA finalises core crypto rules
- Skadden: FCA Finalises Core Rules for the UK Cryptoasset Regime
