V12 found 25 flaws in the x402 codebase, three of them rated critical — and one of those critical mistakes could let a malicious API turn a routine request into a signed payment for an agent’s entire token balance, the firm reported on October 22.
No spending limit in the default client
x402 is an open standard that embeds a payment into the HTTP exchange: a server responds with 402 Payment Required, listing payment options (amount, token, recipient); the client selects an option, signs a payment, and resends the request. V12 reported that the SDKs’ default client historically took the first option on the list and, before fixes released on August 18, set no limit on the amount.
That combination — a server that lists an option for the wallet’s full balance and a client that automatically signs without app-set limits — let a hostile API “turn a routine data request into a request for the wallet's full balance of a supported token,” V12 said. An earlier small payment could reveal the wallet address so the server could look up the balance first; for tokens that support signed transfers, an attacker could then submit the signed payment and collect funds.
The August 18 releases added spend controls to the TypeScript, Python, and Go clients. By default, they now cap each payment at $1 and allow only US dollar stablecoins the SDK recognizes, such as USDC. Apps that pass spendControls: false turn these controls off; teams that cannot upgrade can register a payment policy that drops any option above a set amount.
Token approvals accepted as Solana payments in TypeScript facilitator
On Solana, a merchant’s server relies on a facilitator to validate x402 payments and submit transactions; the facilitator also pays the transaction fee. V12 found 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.
A token approval — which allows a different account to spend tokens later but moves none itself — differs from a transfer only in its first byte. In V12’s local test, the TypeScript facilitator accepted such an approval as a valid payment. V12 called that “a complete payment bypass.” The test did not send a live transaction.
The Python and Go SDKs already checked the instruction type; the August 18 releases added the same check to the TypeScript code. The Hacker News’ package search found every published @x402/svm release from 2.0.0 to 2.22.0 lacked the check, and every release from 2.23.0 on has it.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadSign-In-With-X (SIWx) could sign for other sites
x402’s sign-in extension, Sign-In-With-X (SIWx), lets an agent log in by signing a short message with its wallet. On Ethereum, that message names the website, the wallet address, and a one-time code. V12 reported that the automated client signed these messages without verifying that the website named in them matched the site that had sent the 402 response.
A malicious server could obtain a fresh login message from a different site, pass it to the agent, and use the signature to log in to that other site as the agent’s wallet, V12 said. The August 18 releases change client behavior: TypeScript, Python and Go clients now refuse to sign unless the site in the message matches the site that sent the 402 response. The SIWx specification was also changed to require that refusal.
TypeScript code that calls createSIWxPayload directly must now pass the URL of the 402 response, after redirects. The @x402/fetch and @x402/axios wrappers pass it automatically.
x402 Foundation governance and disclosure
Coinbase created x402 and handed it to the x402 Foundation this year, the foundation said; the x402 Foundation is a Linux Foundation project whose members include Visa and Mastercard. Coinbase holds the most senior seat on the foundation’s technical steering committee, the source notes.
V12 reported the three critical flaws in detail and said the x402 Foundation had already fixed all three in the August 18 releases. However, the foundation has published no security advisory for the three flaws, and its 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. V12 and the x402 Foundation have not publicly reported any attacks using the flaws.
What developers, facilitators, and merchants should do
- Developers: upgrade TypeScript clients by updating @x402/fetch or @x402/axios to 2.23.0 or later (which pulls in the matching @x402/core); update @x402/extensions to 2.23.0 or later if using SIWx. In TypeScript, Go and Python clients, the August 18 releases add spend controls and SIWx checks.
- Facilitators and merchants: ensure @x402/svm is 2.23.0 or later to get the Solana instruction-type check; confirm that facilitator code validates instruction types rather than only token program IDs.
- Teams that cannot upgrade immediately: register a payment policy (registerPolicy in TypeScript and Go; register_policy in Python) to drop options above a set amount; Python’s package includes a ready-made max_amount policy.
- V12’s advice: check that a SIWx login message identifies the site contacted before signing, set per-payment and total budgets, and limit which tokens, networks, and recipients a client will pay.
Upgrading also brings later fixes, including a September fix for a separate payment bypass in @x402/core 2.27.0. As of October 23, the latest published package 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.
The record in the public packages is clear: critical fixes exist and are available, but prior releases and common dependency checks did not flag the problems. Developers and merchants using x402-based payments should confirm their clients and facilitators are on the fixed releases or are enforcing equivalent policies before exposing agents to networks of third-party APIs.
