V12 disclosed critical x402 SDK flaw letting malicious APIs drain AI agent wallets

V12 disclosed on Oct. 22, 2026 that AI agents using x402 SDKs could sign a payment for their full token balance if a malicious API requested it, because the default client imposed no spending limit. The x402 Foundation released patches on Aug. 18, 2026 that add a $1 default cap and restrict payments to recognized US dollar stablecoins such as USDC.

x402 lets software, including AI agents, pay for an API call inside the web request itself without manual approval for each payment. A server seeking payment answers with the 402 Payment Required status and lists payment options, each with an amount, a token, and a recipient. The client selects one option, signs a payment, and resends the request. Before the fix, the default client selected the first listed option and set no cap on the amount.

V12 said a hostile API could transform an ordinary data request into a demand for the wallet’s complete balance of a supported token. An earlier small payment could expose the wallet address, enabling the server to check the balance beforehand. Given an automatic signer and no app-set payment policy, the client could authorize a payment for that amount. For a token supporting signed transfers, the attacker could submit the signed authorization and take the funds.

Automatic signers without application-level caps were the only agents exposed to the full-balance payment risk. Deployments that reviewed each request or set explicit caps did not share that exposure. V12’s analysis indicates the exposure was narrower than it might first appear.

V12 found 25 flaws in the x402 code and rated three of them critical, describing those in detail. The x402 Foundation maintains the SDKs and addressed all three critical flaws in releases dated Aug. 18, 2026. The August 18 updates introduced spending limits for the TypeScript, Python, and Go client libraries. After the update, the default limit is $1 per payment, and the client accepts only recognized US dollar stablecoins such as USDC.

The second critical flaw sits in the TypeScript facilitator code for Solana. The facilitator verified that a payment invoked an allowed token program but did not check the instruction type. V12 characterized the facilitator’s acceptance of a token approval as payment as “a complete payment bypass.” A token approval permits another account to spend tokens later while moving none itself, and it differs from a transfer only in its first byte.

In V12’s local test, the facilitator accepted a token approval as a valid payment, though the test did not send a live transaction. V12 said a merchant that depends on the facilitator might hand over a paid resource without receiving any tokens. On Solana, the facilitator covers the transaction fee as well. Every published @x402/svm release from 2.0.0 to 2.22.0 lacks the Solana instruction-type check, while every release from 2.23.0 onward has it.

Only the TypeScript x402 SDK had the Solana facilitator flaw; the Python and Go SDKs already checked the Solana instruction type before the August 18 releases. Solana facilitators validating payments must run @x402/svm 2.23.0 or later to enforce the instruction-type check.

The third critical flaw V12 described involved Sign-In-With-X. The automated SIWx client signed login messages without verifying that the website named in them matched the site it had contacted. A hostile server could fetch a login message from a different site, deliver it to the agent, and use the resulting signature to authenticate on that site with the agent’s wallet. The August 18 releases make TypeScript, Python and Go clients refuse SIWx signatures unless the site in the message matches the site that sent the 402 response.

Direct callers of createSIWxPayload in TypeScript must now supply the URL of the 402 response, including any redirects. The @x402/fetch and @x402/axios wrappers send the response URL without extra work, leaving direct callers to handle it themselves.

As of Oct. 23, current releases 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. TypeScript applications get the spending limit by upgrading @x402/fetch or @x402/axios to 2.23.0 or later, which brings in the corresponding @x402/core. Applications using Sign-In-With-X also need @x402/extensions 2.23.0 or later, which contains the login site-matching check. Upgrading to the latest releases also delivers a September fix for a separate payment bypass in @x402/core 2.27.0.

No public CVE exists for the flaw; V12’s advisory tracks it. On Oct. 23, npm audit showed no advisories for the vulnerable TypeScript releases before the fixes, and PyPI listed no vulnerabilities for the last Python release ahead of them. A developer who relies on npm audit or PyPI checks receives no warning to upgrade. The x402 Foundation has published no security advisory for the three critical flaws, and its changelogs list the fixes without calling them security fixes.

Teams stuck on older clients can register a payment policy that rejects any option over a set amount. Older clients support registerPolicy in TypeScript and Go and register_policy in Python, which also has a ready-made max_amount policy. Apps that pass spendControls: false turn all spend controls off, leaving patched SDKs exposed if the application explicitly overrides the spending limit back to unlimited.

V12 advises checking that a SIWx login message identifies the site contacted before signing, setting budgets for each payment and in total, and limiting which tokens, networks, and recipients a client will pay. V12 uncovered the flaws through code review and local testing. Neither V12 nor the x402 Foundation has publicly disclosed any exploitation of the flaws. No one has reported confirmed in-the-wild exploitation, and no CISA KEV entry exists.

RedSide Security summarizes the impact of the missing spending limit for autonomous agents: in practical terms, a single hostile response could empty an agent’s wallet. The flaw was a trust-boundary failure, not a remote code execution bug or key-theft primitive. The API server, not the agent’s operator, effectively controlled the payment amount.

The window between the permissive default shipping and the fix arriving was roughly the length of a normal release cycle. The attacker needed a token account with no balance, and the facilitator paid the transaction fee each time. RedSide notes the exposure was narrower than the worst-case scenario suggests.

Security Arsenal warns that patching the SDK does not help if the application disables the new defaults. There is no exploit to block at the perimeter for this flaw.

Coinbase created x402 and transferred it to the x402 Foundation this year. The x402 Foundation is a Linux Foundation project, and Visa and Mastercard are among its members. Coinbase occupies the most senior seat on the foundation’s technical steering committee.

V12 disclosed the flaws through code review and local experimentation rather than observed exploitation. The disclosure came on Oct. 22, 2026, and patches shipped Aug. 18, 2026. Teams should verify they are running fixed releases and that no application overrides the default spending limit.