x402 SDK Critical Flaws: How a Malicious API Could Drain an AI Agent Wallet

On October 22, 2026, security firm V12 published research on x402, the open protocol that lets software, including AI agents, pay for APIs over HTTP 402 responses, and rated three of its SDK bugs critical. All three were fixed in releases on August 18. None came with a security advisory, so npm audit and PyPI stay quiet about older versions. If an agent of yours holds a wallet and uses x402, check which version it runs. The bugs are described by The Hacker News, which reported them on October 23, and by V12's own write-up.

TL;DR

The three critical bugs

1. No default spending limit

The default client took the first payment option the server listed and set no amount limit. A hostile API could ask for the wallet's full balance of a supported token. A small earlier payment can reveal the wallet address, so the server can check the balance first. If the agent signs automatically and the app set no policy, the client signs that amount, and for tokens that support signed transfers the attacker submits it and collects.

The fix caps each payment at $1 by default and allows only US dollar stablecoins the SDK recognizes, such as USDC. It affected the default client in TypeScript, Python and Go before the August 18 releases.

2. Token approvals accepted as Solana payments (TypeScript only)

The Solana facilitator checked that a payment called an allowed token program but did not check the instruction type. A token approval moves no tokens and differs from a transfer only in its first byte. In V12's local test the facilitator accepted an approval as a valid payment, which V12 called "a complete payment bypass": a merchant could deliver a paid resource and receive nothing. The test did not send a live transaction.

Every @x402/svm release from 2.0.0 through 2.22.0 lacks the check; 2.23.0 and later include it. The Python and Go SDKs already checked instruction type.

3. Logins signed for other websites

The automated client signed Sign-In-With-X (SIWx) messages without checking that the site named in the message was the site it had contacted. A malicious server could fetch a fresh login message from another site, hand it to the agent, and use the signature to log in there as the agent's wallet, wherever that site accepts the relayed message.

The August 18 TypeScript, Python and Go clients refuse to sign unless the site in the message matches the site that sent the 402 response, and the SIWx specification now requires clients to refuse in that case.

Why "no advisory" is the real problem

Fixes shipped, but the changelogs list them without calling them security fixes. That means a team running a scanner has no signal that an old x402 version is dangerous, and the one default that mattered (no spending limit) is a missing safeguard rather than a bug a scanner could match. Anyone who pinned a version in spring and never looked again is still exposed.

What to do

1. Find x402 in your agents. Search lockfiles and manifests for @x402/, and the Python and Go equivalents.
2. Upgrade. TypeScript clients to @x402/fetch or @x402/axios 2.23.0 or later; SIWx apps to @x402/extensions 2.23.0 or later; Solana facilitators to @x402/svm 2.23.0 or later. Latest as of October 23: 2.28.0 (TypeScript, Go), 2.25.0 (Python).
3. Keep the new spend controls on. After upgrading, payments are capped at $1 and limited to recognized stablecoins unless you set your own. Passing spendControls: false turns this off, so avoid it unless you have a stricter policy.
4. If you cannot upgrade, register a payment policy that drops any option above a set amount: registerPolicy in TypeScript and Go, register_policy with the ready-made max_amount policy in Python.
5. Follow V12's advice: verify a SIWx message names the contacted site before signing, set per-payment and total budgets, and limit tokens, networks and recipients.
6. Fund agent wallets minimally. An agent wallet should hold what the agent needs for a day, not a treasury.

What this means for people running coding agents

An agent that can pay is an agent with credentials that spend. The same discipline applies as for API keys: least privilege, small balances, and a record of what the agent did. Beam watches what coding agents run on your machine and flags credential and config access, which helps you see which agents are wired to wallets or payment keys, but it does not inspect on-chain payments or replace a spending cap in the payment SDK itself.

What to watch for

• A published advisory or CVE from the x402 Foundation.
• Any report of these bugs being exploited.
• V12's remaining 21 findings, which were not rated critical.

Details are accurate as of October 23, 2026.

Related reading

• October 2026 attacks timeline
• Railway breach: environment variables accessed, rotate every secret
• LLMjacking via hijacked GCP billing accounts

Sources: The Hacker News: Critical x402 SDK flaw · V12 research on x402 · x402 Foundation repository · SIWx specification