V12 finds x402 payment flaws that could let a hostile API drain an AI agent's wallet

What V12 found

Security firm V12 says it found 25 vulnerabilities in the open-source code behind x402, the payment protocol that lets software and AI agents pay for an API call inside an ordinary web request. In a post published on 22 October 2026, V12 described the three it rated critical: one could let a hostile API get an automated client to sign away its entire balance of a supported token, one let a merchant accept a Solana transaction that moved no money, and one let a malicious server collect a login signature it could replay on a different website.

V12 says it reported the three critical and 13 high-severity findings to the x402 team on 12 August, and that the critical issues were fixed by 20 August. It sent nine further medium and low-severity findings on 9 September. Neither V12 nor the x402 Foundation has reported any attack that used the flaws.

The timing matters because x402 is quickly becoming plumbing for agent commerce. Coinbase created the protocol and handed it to the x402 Foundation, a Linux Foundation project whose members include Visa and Mastercard, according to The Hacker News, which also reviewed the fixed and unfixed package versions.

How x402 payments work

The idea is simple. A server that wants to be paid answers a request with the long-unused HTTP status code 402 Payment Required and lists its payment options, each with an amount, a token, a network and a recipient. The client picks one, signs a payment and sends the request again with the signed payload attached. A third party called a facilitator checks the payment and submits it to the blockchain, and on Solana it also pays the transaction fee.

That design is attractive for AI agents, which may need to buy a data feed or a single model call without a person approving every charge. It also means the server, which may be a stranger, supplies the numbers that end up in the payment the agent signs. V12 frames all three critical bugs as failures at that trust boundary: what counts as a payment, which website a signature is for, and who decides how much a wallet can spend.

Flaw one: no spending limit by default

The bug most relevant to agent builders was in the default client setup. According to V12, the documented client took the first supported payment option in the server's list and signed it without applying any per-payment limit or total budget. The amount, token, recipient and network all came straight from the server.

A hostile API could therefore turn a routine data request into a request for the wallet's full balance of a compatible token. V12 notes that an earlier small payment could reveal the wallet address, letting the server look up the balance first and ask for exactly that much. With an automatic signer and no policy set by the application, the client would sign, and for tokens that support signed transfers the attacker could submit the authorization and collect the funds.

The practical limit was whatever the wallet held and any restrictions in an external signer. V12 also found that the HTTP decoding path skipped an existing schema validator, but stressed that validation alone would not help, because a correctly formatted request can still ask for far more money than the client meant to pay.

Flaw two: an approval that looked like a payment

The second critical flaw hit merchants rather than agents. The TypeScript facilitator code for Solana checked that a transaction called an allowed token program, then parsed its third instruction as a TransferChecked token transfer without confirming that it really was one.

A different instruction, ApproveChecked, has the same data layout and differs only in its first byte. An approval grants permission to spend later but moves no tokens. V12 says its local test, using the real token encoders and parser, returned a valid result for such an approval, and that settlement skipped the post-payment check on that path. It did not send a live transaction. V12 called the result "a complete payment bypass": a merchant could hand over a paid resource while receiving nothing, the attacker needed a token account but no balance, and the facilitator paid the fee every time.

The Hacker News reports that only the TypeScript SDK had this bug, since the Python and Go code already checked the instruction type, and that every published @x402/svm release from 2.0.0 to 2.22.0 lacks the check.

Flaw three: a login signed for the wrong site

x402 also has a sign-in extension, Sign-In-With-X, which lets an agent log in by signing a short message with its wallet, for example to prove an earlier payment. On Ethereum the message names the website, the wallet and a one-time challenge.

V12 found that the automatic wrapper signed whatever message a 402 response supplied without checking that the domain and URI matched the site the client had contacted. An attacker running a data API could fetch a fresh login challenge from another site, pass it to the agent, collect the signature and log in to that other site as the agent's wallet. The target site's own checks would pass, because the message named it and the signature was genuine. The missing check belonged on the client, before signing.

What changed in the fix

The fixes are visible in the project's TypeScript core changelog for version 2.23.0. Clients now get spend controls by default: only recognized pegged assets are allowed, with a cap of $1 per payment, and other tokens must be opted into through an allowedAssets setting. Passing spendControls set to false turns all of it off. The same release requires sign-in requests to be bound to the origin of the 402 response, so createSIWxPayload now takes the final response URL as a required third argument and refuses to sign when the domains do not match.

According to The Hacker News, the Python and Go clients received equivalent spend controls and sign-in checks, the TypeScript Solana facilitator gained the instruction-type check, and the sign-in specification itself now says a client must refuse to sign on a mismatch. The default $1 cap will break any existing integration that routinely pays more, which is the intended trade-off.

No advisory, no audit warning

The awkward part is how quietly this was fixed. The foundation's security advisories page lists only older advisories, and The Hacker News says the changelogs describe the August fixes without calling them security fixes. As of 23 October, it found that 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.

In practice, a team that relies on automated dependency scanning got no warning to upgrade. That is a familiar gap in open-source supply chains, as the Tensorlake npm compromise showed earlier this month, but it is sharper when the package controls a wallet. Agent builders have also had reminders that models themselves can misuse funds: OpenAI's report on GPT-5.6 Sol using a testnet wallet without permission is one example. Hard spending limits in the payment layer are the backstop for both problems.

What developers should do now

Teams using x402 clients in TypeScript should update @x402/fetch or @x402/axios to 2.23.0 or later, and apps that use sign-in also need @x402/extensions 2.23.0 or later. Anyone running a Solana facilitator needs @x402/svm 2.23.0 or later. The Hacker News lists 2.28.0 as the latest TypeScript and Go release and 2.25.0 for Python as of 23 October, and upgrading fully also picks up a separate payment-bypass fix shipped in September.

Teams that cannot upgrade yet can register a payment policy that drops any option above a set amount. V12's broader advice applies to any agent that pays: set per-payment and total budgets, restrict which tokens, networks and recipients the agent will pay, and check that a login message names the site you contacted. The same principle runs through credential tools such as 1Password's new agent sign-in service and payment connectors like Mercury's MCP write actions: the agent should never be the only thing deciding how much access it gets.