> ## Content Index
> Fetch the complete content index at: https://stablecoininsider.org/llms.txt
> Use this file to discover other available public pages before exploring further.

# x402 Vulnerabilities: 3 Critical Flaws and How to Patch
- URL: https://stablecoininsider.org/x402-vulnerabilities/
- Published: 2026-10-25T13:23:01.000Z
- Updated: 2026-10-25T13:23:03.000Z
- Description: V12 disclosed 25 x402 vulnerabilities on 22 October, three of them critical: no default spending limit, a Solana payment bypass and cross-site login signing. Stablecoin Insider explains each flaw, who is still exposed and how to patch agents that pay in USDC.
- Author: Alexandra
- Tags: AI, Stablecoins, AI Agents, x402, USDC, Security

x402 lets an AI agent pay for an API call in USDC inside the same HTTP request. On 22 October 2026 security firm V12 published 25 x402 vulnerabilities, three of them rated critical, including one that let a hostile API ask an agent to sign away its whole token balance ([V12](https://v12.sh/blog/x402)).

The fixes have existed since 18 August. The x402 Foundation never published a security advisory, so npm audit and PyPI still show no warning for the vulnerable releases ([The Hacker News, 23 October 2026](https://thehackernews.com/2026/10/critical-x402-sdk-flaw-could-let.html)).

Stablecoin Insider pulled npm's per-version download counts to see how many builds still pull old code. The short answer: a lot. This guide covers what each flaw does, who it hurts, what the numbers show and the exact upgrade path.

### Key Takeaways

- V12 found 25 x402 vulnerabilities; three were critical and are now fixed ([V12](https://v12.sh/blog/x402)).
- Before 18 August, the default x402 client set no spending limit at all ([The Hacker News](https://thehackernews.com/2026/10/critical-x402-sdk-flaw-could-let.html)).
- Patched clients cap each payment at $1 and allow only recognized USD stablecoins by default ([x402 changelog](https://github.com/x402-foundation/x402/blob/main/typescript/packages/core/CHANGELOG.md)).
- 55.2% of @x402/fetch downloads in the past week were 2.x builds older than 2.23.0 ([npm](https://api.npmjs.org/versions/%40x402%2Ffetch/last-week)).
- No security advisory exists, so npm audit stays silent on the vulnerable versions ([pwn.watch](https://pwn.watch/i/x402-sdk-critical-flaws-v12)).

## What V12 found in the x402 code

Let's start with the timeline. V12 reported 3 critical and 13 high-severity findings to the x402 team on 12 August 2026\. The critical ones were fixed by 20 August, and another 9 medium and low findings went in on 9 September ([V12 disclosure](https://v12.sh/blog/x402)).

The fixed TypeScript packages shipped as version 2.23.0 on 18 August 2026, according to the npm registry timestamps for @x402/fetch ([npm registry](https://registry.npmjs.org/@x402/fetch)). V12 went public with the write-up on 22 October, more than two months later.

Neither V12 nor the foundation has reported any attack using the flaws ([The Hacker News](https://thehackernews.com/2026/10/critical-x402-sdk-flaw-could-let.html)). That's good news. It doesn't make an unpatched agent safe.

Some context on who owns the code. Coinbase created x402 and handed it this year to the x402 Foundation, a Linux Foundation project whose members include Visa and Mastercard ([The Hacker News](https://thehackernews.com/2026/10/critical-x402-sdk-flaw-could-let.html)). If you're new to the protocol itself, Stablecoin Insider's [x402 explainer](https://stablecoininsider.org/x402-protocol/) covers the 402 handshake from the start.

## Critical flaw 1: no spending limit in the default client

This is the one that matters most for anyone running a funded agent. A server that wants payment answers with HTTP 402 and a list of options: amount, token, recipient. The default client took the first option and, before the fix, applied no cap on the amount ([V12](https://v12.sh/blog/x402)).

So a hostile API could turn a routine data request into a request for the wallet's full balance. An earlier small payment could reveal the wallet address, letting the server check the balance first. With an automatic signer and no app-level policy, the client signed it ([The Hacker News](https://thehackernews.com/2026/10/critical-x402-sdk-flaw-could-let.html)).

The 2.23.0 release added client spendControls. By default only recognized pegged assets are allowed, with a $1 USD cap per payment; apps can opt into other tokens through allowedAssets, or pass spendControls: false to switch every control off ([@x402/core changelog](https://github.com/x402-foundation/x402/blob/main/typescript/packages/core/CHANGELOG.md)).

That last option is the trap. One config flag puts you back where you were in July.

## Critical flaw 2: a Solana approval counted as a payment

The second flaw hits merchants, not agents. The TypeScript Solana facilitator checked that a transaction called an allowed token program, then parsed the third instruction as TransferChecked without confirming the instruction type ([V12](https://v12.sh/blog/x402)).

ApproveChecked has the same data layout. V12 shows the two differ only in the first byte, 0c for a transfer and 0d for an approval. An approval grants spending rights but moves no tokens, so a merchant could deliver a paid resource and receive nothing, while the facilitator paid the fee each time ([V12](https://v12.sh/blog/x402)).

Every published @x402/svm release from 2.0.0 to 2.22.0 lacks the check; the Python and Go SDKs already had it ([The Hacker News](https://thehackernews.com/2026/10/critical-x402-sdk-flaw-could-let.html)). The 2.23.0 changelog describes the fix only as an added "validation guard for TransferChecked" ([@x402/svm changelog](https://github.com/x402-foundation/x402/blob/main/typescript/packages/mechanisms/svm/CHANGELOG.md)).

If you run or choose a facilitator, this is the version number to ask about. Stablecoin Insider's guide on [how to choose an x402 facilitator for USDC](https://stablecoininsider.org/how-to-choose-an-x402-facilitator-for-usdc/) lists the other questions worth asking.

## Critical flaw 3: logins signed for the wrong website

x402 has a sign-in extension, Sign-In-With-X (SIWx), that lets an agent log in with its wallet instead of paying again. The automatic wrapper signed the login message from a 402 response without checking that its domain and URI matched the site the agent had contacted ([V12](https://v12.sh/blog/x402)).

A malicious data server could fetch a fresh login challenge from another site, pass it to the agent and replay the signature there. The attacker then held whatever access that session allowed, regardless of the price of the original request ([V12](https://v12.sh/blog/x402)).

From 2.23.0, createSIWxPayload takes a required third argument, the final URL of the 402 response after redirects, and refuses to sign when the origins don't match ([@x402/extensions changelog](https://github.com/x402-foundation/x402/blob/main/typescript/packages/extensions/CHANGELOG.md)). The @x402/fetch and @x402/axios wrappers pass that URL on their own.

## The three critical x402 flaws at a glance

The table below maps each flaw to the party it hurts and the first fixed release, using the V12 write-up and the pwn.watch fix brief ([pwn.watch](https://pwn.watch/i/x402-sdk-critical-flaws-v12)).

| Flaw                                          | Who gets hurt                                  | Affected                                                                                       | Fixed in                                                 |
| --------------------------------------------- | ---------------------------------------------- | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------- |
| No default spending limit                     | Agent owners with funded, auto-signing wallets | @x402/fetch and @x402/axios before 2.23.0; Python and Go clients before the 18 August releases | 2.23.0 ($1 default cap, recognized USD stablecoins only) |
| Solana ApproveChecked read as TransferChecked | Merchants and facilitators on Solana           | @x402/svm 2.0.0 to 2.22.0 (TypeScript only)                                                    | @x402/svm 2.23.0                                         |
| SIWx signs logins for other sites             | Agents whose wallets log in to other services  | @x402/extensions before 2.23.0; Python and Go clients before the 18 August releases            | @x402/extensions 2.23.0 (origin check)                   |

⚠️

No CVE, no advisory: the x402 Foundation's changelogs list these fixes without calling them security fixes, so dependency scanners that rely on advisories won't flag the old versions. Check version numbers by hand.

## How many builds still pull vulnerable x402 versions

Here's why the missing advisory matters. Stablecoin Insider read npm's per-version download counts for the past seven days on 25 October 2026\. For @x402/fetch, **66,488 of 120,538 downloads (55.2%) were 2.x versions older than 2.23.0, and only 42,824 were the latest 2.28.0** ([npm versions API](https://api.npmjs.org/versions/%40x402%2Ffetch/last-week)).

| Package                                                                           | Downloads, past 7 days | 2.x before 2.23.0 | 2.23.0 or later | On 2.28.0 |
| --------------------------------------------------------------------------------- | ---------------------- | ----------------- | --------------- | --------- |
| [@x402/fetch](https://api.npmjs.org/versions/%40x402%2Ffetch/last-week)           | 120,538                | 66,488 (55.2%)    | 54,047 (44.8%)  | 42,824    |
| [@x402/extensions](https://api.npmjs.org/versions/%40x402%2Fextensions/last-week) | 97,040                 | 47,550 (49.0%)    | 49,488 (51.0%)  | 24,767    |
| [@x402/svm](https://api.npmjs.org/versions/%40x402%2Fsvm/last-week)               | 73,196                 | 21,249 (29.0%)    | 51,944 (71.0%)  | 36,092    |
| [@x402/core](https://api.npmjs.org/versions/%40x402%2Fcore/last-week)             | 307,037                | 121,765 (39.7%)   | 185,268 (60.3%) | 118,926   |
| [@x402/axios](https://api.npmjs.org/versions/%40x402%2Faxios/last-week)           | 756                    | 269 (35.6%)       | 487 (64.4%)     | 460       |

Read the numbers with care. Downloads aren't deployments: CI runners, caches and lockfiles all inflate or distort them. But the direction is clear. Roughly half of @x402/fetch and @x402/extensions pulls, and 29.0% of @x402/svm pulls, still land on code without the fixes ([npm](https://api.npmjs.org/versions/%40x402%2Fsvm/last-week)).

One more line item. The older unscoped x402 package logged 355,957 downloads in the same window, and its latest release, 1.2.0, dates from 16 April 2026 ([npm registry](https://registry.npmjs.org/x402)). The published fix lists cover the scoped @x402 packages, Python and Go, not that package, and Stablecoin Insider has not tested whether it shares the flaws. If your stack still imports it, treat that as an open question.

## How to patch an x402 agent or facilitator

The upgrade path comes from The Hacker News' version check and the foundation's changelogs. As of 23 October the latest releases were 2.28.0 for the TypeScript packages and the Go module, and 2.25.0 for Python ([The Hacker News](https://thehackernews.com/2026/10/critical-x402-sdk-flaw-could-let.html)).

First, see what you actually have installed:

```bash
npm ls @x402/fetch @x402/axios @x402/extensions @x402/svm @x402/core x402
```

Then work through the list:

1. Agent clients: move @x402/fetch or @x402/axios to 2.23.0 or later (2.28.0 is current). That pulls in the matching @x402/core and the $1 default cap.
2. SIWx users: move @x402/extensions to 2.23.0 or later. If you call createSIWxPayload directly, pass the final 402 response URL as the third argument.
3. Solana facilitators: move @x402/svm to 2.23.0 or later before verifying another payment.
4. Python and Go: upgrade past the 18 August releases. On PyPI that's x402 2.20.0, uploaded 18 August 2026, with 2.25.0 the latest ([PyPI](https://pypi.org/project/x402/#history)).
5. Servers: take 2.27.0 or later too. It closes a separate bypass where an encoded path such as /api%2Fpremium could reach a paid route unpaid ([@x402/core changelog](https://github.com/x402-foundation/x402/blob/main/typescript/packages/core/CHANGELOG.md)).

Can't upgrade this week? Older clients support a payment policy that drops any option above a set amount: registerPolicy in TypeScript and Go, register\_policy in Python, which also ships a ready-made max\_amount policy ([The Hacker News](https://thehackernews.com/2026/10/critical-x402-sdk-flaw-could-let.html)).

Whatever version you run, don't rely on the $1 default alone. V12's advice is to set a per-payment and a total budget and to limit tokens, networks and recipients before the client signs ([V12](https://v12.sh/blog/x402)).

[x402 Explained: HTTP 402 Payments for AI Agents in 2026Stablecoin Insider's explainer on how the x402 handshake works, who uses it and how USDC settles.![](https://stablecoininsider.org/favicon.ico)Stablecoin Insider](https://stablecoininsider.org/x402-protocol/)

## What the x402 flaws mean for agent payments

At first glance, these look like ordinary SDK bugs. They're not quite. Each one crossed a trust boundary that agent payments depend on: what counts as a payment, which site a signature is for, and who decides how much the wallet can spend ([V12](https://v12.sh/blog/x402)).

The spending flaw is the sharpest. An agent that pays automatically is only as safe as the limit its software enforces, and here the shipped default was no limit. That raises the question Stablecoin Insider covered in [who is liable when an AI agent overspends](https://stablecoininsider.org/who-is-liable-when-an-ai-agent-overspends/): if a hostile API drains a wallet, the operator who skipped the cap will struggle to push the loss onto anyone else.

Wallet design is the second line of defence. A custodial agent wallet with server-side policy can enforce caps even when the SDK doesn't; a raw hot key can't. The trade-offs are laid out in [custodial vs non-custodial agent wallets](https://stablecoininsider.org/custodial-vs-non-custodial-agent-wallets/).

💡

Stablecoin Insider's take: x402's design held up. The bugs sat in default settings and parsing shortcuts, and the fixes were small. What failed was disclosure. Shipping a fix for a drain-the-wallet bug as a routine minor release, with no advisory, left roughly half of last week's @x402/fetch downloads on old code two months later. For a standard that Visa and Mastercard now sit behind, that's the part to fix next. Until advisories catch up, treat every x402 dependency as unpatched until you've checked its version number yourself.

[How to accept x402 USDC payments safely](https://stablecoininsider.org/how-to-accept-x402-usdc-payments-from-ai-agents/)

---

## FAQ

#### What are the x402 vulnerabilities V12 found?

V12 found 25 flaws in the x402 code. The three critical ones were a default client with no spending limit, a Solana facilitator that accepted token approvals as payments, and SIWx signing logins for other sites ([V12](https://v12.sh/blog/x402)).

#### Has anyone lost money to the x402 flaws?

No attacks have been publicly reported. Neither V12 nor the x402 Foundation has disclosed any exploitation ([The Hacker News](https://thehackernews.com/2026/10/critical-x402-sdk-flaw-could-let.html)).

#### Which x402 version fixes the critical flaws?

Version 2.23.0 of @x402/fetch, @x402/axios, @x402/extensions and @x402/svm, released 18 August 2026\. The latest is 2.28.0 ([pwn.watch](https://pwn.watch/i/x402-sdk-critical-flaws-v12)).

#### Why doesn't npm audit flag the old x402 versions?

Because the x402 Foundation published no security advisory or CVE for the three flaws. Scanners that read advisories see nothing to report ([The Hacker News](https://thehackernews.com/2026/10/critical-x402-sdk-flaw-could-let.html)).

#### Is the $1 default cap enough for my agent?

Not on its own. Set your own per-payment and total budgets and an allowlist of tokens, networks and recipients, and never ship spendControls: false in production.

#### Does this affect USDC itself?

No. USDC and the chains it runs on weren't affected. The flaws sat in x402 client, facilitator and sign-in code that moves USDC on an agent's behalf.

## What to watch next

Two things. First, whether the x402 Foundation publishes formal advisories for the August fixes, which would finally make npm audit and PyPI flag the old versions. Second, the 22 non-critical findings V12 hasn't detailed yet; 13 of them were rated high ([V12](https://v12.sh/blog/x402)).

If you run an agent that pays in stablecoins, Monday's job is short: run npm ls, upgrade anything below 2.23.0, search your code for spendControls: false, and set a budget you'd be comfortable losing.

This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, security-audit or tax advice. Package versions and download counts change daily, so check the x402 Foundation's current releases before you deploy. No material herein should be interpreted as a recommendation, endorsement, or solicitation to buy or sell.