x402's critical SDK flaws, and what a check outside the agent stops

Frits Zwager, Fizzl · 29 October 2026 · Trust Index numbers from the scan of 29 October 2026

On 22 October 2026 the security firm V12 published a review of the x402 SDKs: 25 flaws, three of them critical. The worst let a hostile API ask an agent that signs automatically for its whole balance of a supported token. All three were fixed on 18 August, but without a security advisory, so npm audit and Dependabot still show the old versions as clean. Here is what the flaws were, what we see in the x402 market, and what an independent check before signing does and doesn't stop.

The three critical flaws

• No default spending limit (buyers). The default x402 client took the first payment option a server listed and signed it, with no cap. A hostile API could first take a small payment to learn the wallet address, read its balance, and then ask for all of it. This only hits agents that sign automatically without their own payment policy. Fixed in @x402/fetch and @x402/axios 2.23.0, which cap each payment at $1 and accept only recognised dollar stablecoins unless the app sets its own controls.
• A token approval accepted as a payment (Solana sellers). The TypeScript Solana facilitator checked that a transaction called the token program, but not which instruction: an approval, which moves no tokens, passed as a transfer. The two differ in one byte. Every @x402/svm release from 2.0.0 to 2.22.0 has this; 2.23.0 checks it. The Python and Go SDKs already did. V12 showed it in a local test, not on mainnet.
• A Sign-In-With-X signature for another site (buyers). The automated client filled in the domain of a login message from the server's 402 without checking it against the site it had contacted. A malicious server could relay another site's login message, have the agent sign it, and log in there as the agent's wallet. Fixed in @x402/extensions 2.23.0; the SIWx specification now requires the check.

V12 reported 3 critical and 13 high findings to the x402 team on 12 August; the fixes followed six days later. A separate payment bypass was fixed in @x402/core 2.27.0 in September. Neither V12 nor the x402 Foundation has reported an attack using these flaws. The other 22 findings have not been described in public.

Why your scanner says nothing

The changelogs list the fixes without calling them security fixes, and no advisory or CVE was filed. On 23 October npm audit showed no advisory for the last vulnerable TypeScript releases, and PyPI listed none for the last vulnerable Python release. As the Cloud Security Alliance put it: "a clean SCA report is not evidence that x402 dependencies are safe." Compare version numbers yourself:

The current release, 2.29.0, also moves the x402 packages to zod 4 (see our zod article). Upgrading takes a few changes of its own; that article lists them.

What the market asks: 548 endpoints above the new $1 cap

We looked at what the 98,349 payable endpoints in the x402 Doctor Trust Index asked per call on 29 October 2026:

So 99.4% of payable endpoints ask $1 or less, and the new default cap leaves them alone. The other 548 will be refused by a patched client until the buyer sets a budget, which is what you want: paying $5 or $200 for a call should be a decision, not a default. At the top, one endpoint asks $1,000,000 a call and several ask $1,000 or more. Whether those are mistakes or traps, an agent without a budget would have signed them.

Until today, x402 Doctor's own preflight also said "go" to such a price when it was asked without a max_usd. From now on a price above $100 a call without a budget is a caution (price_very_high), and the Trust Index marks those endpoints the same way from its next scan.

What a check outside the agent stops

The CSA's advice is to enforce limits outside the agent, "in a signing proxy, policy engine, or custodial wallet service", because settings inside the process can be influenced by a prompt-injected agent. That is what our tools do. Per flaw:

What none of this does: decide what a call is worth. A 402 that asks $200 honestly, for the right recipient and token, passes presign-guard; only a budget stops it. The CSA again: "the payer's policy decides what is paid, and the payee's request is only a proposal."

What to do now

• Buyers: upgrade every @x402/* package together to 2.23.0 or later (2.29.0 is current), search your code for spendControls: false and custom selectors that skip the policy, and keep agent wallets at a working balance.
• Set a budget in the call, not just a cap in the SDK: pass max_usd to a preflight, or use a wallet that keeps limits outside the agent.
• Sign-In-With-X: if you call createSIWxPayload yourself, pass the URL of the 402 response after redirects; @x402/fetch and @x402/axios do this for you.
• Sellers and facilitators: @x402/svm 2.23.0 or later and @x402/core 2.27.0 or later, and reconcile settlements with the tokens that actually arrived.

How we checked

• The flaws, timeline and versions from The Hacker News (23 Oct 2026) and the Cloud Security Alliance research note (25 Oct 2026), which both rely on V12's write-up. V12 sells a security product, which the CSA notes as a possible bias.
• Prices: the cheapest payable option of every endpoint the Trust Index rated go or caution in its scan of 29 October 2026 (98,349 endpoints, 98,147 with a dollar price).
• Our own services run @x402/* 2.29.0 since 29 October 2026.

Questions

Is my x402 agent affected?

If it pays with @x402/fetch or @x402/axios older than 2.23.0, signs automatically and sets no payment policy, a hostile API could ask it for its whole balance of a supported token. Upgrade to 2.23.0 or later (2.29.0 is current), or register a policy that drops any option above your budget. npm audit will not tell you: no advisory was published.

Will the new $1 default cap break anything?

It refuses any payment above $1 unless your app sets its own spend controls. On 29 October 2026, 548 of 98,349 payable endpoints in the x402 Doctor Trust Index (196 sellers) asked more than $1 a call. An agent that buys from those needs an explicit budget; that is the point of the change.

Does presign-guard catch these attacks?

It checks what the wallet is about to sign, outside the agent. A Sign-In with Ethereum message for another site than the one asking is red (SIGN_IN_DOMAIN_MISMATCH). An EIP-3009 x402 payment that pays more, someone else, another token or another chain than the 402 asked is red. It does not decide your budget: an honest-looking 402 that simply asks a lot passes, so set limits in the wallet as well.

What should a seller or facilitator do?

Run @x402/svm 2.23.0 or later if you verify Solana payments, and @x402/core 2.27.0 or later. Check settlements against the tokens that actually arrived, not only the facilitator's answer.

Check an x402 endpoint before you pay it with x402 Doctor, and a payment or message before you sign it with presign-guard.