What a disclosed x402 SDK flaw looks like on Base, measured

On 22 October 2026 the security firm V12 reported that the x402 client SDKs, before version 2.23.0, signed whatever amount a 402 response asked for. The default client had no spending limit, so a hostile API could turn a routine request into a request for the wallet's full balance of a supported token. The fix shipped in the 18 August releases: a $1 cap per payment and recognised dollar stablecoins only, by default. No security advisory was published, and npm audit shows nothing for the vulnerable versions (The Hacker News, 23 Oct 2026).

That is the code side. We read the settlement side.

The question

Every stablecoin transfer into an x402 seller listed in the Bazaar on Base lands in our ledger (definition x402.settle.submitter.v4). So: how often does a settlement arrive far above what the seller is usually paid?

The numbers

Measured 2026-10-24T08:50Z, for 12 to 23 October 2026, at the 80 sellers with 20 or more settlements in the window (32,605 settlements, $18,950.78 in total):

Rule	Settlements
At least 10× the seller's median	1,126 (3.5%)
At least 100× the seller's median	65
At least 100× and at least $1	25, worth $1,928.23, from 13 payers to 7 sellers

The largest cases:

Settlement	Seller's median	Seller's settlements in the window
$588.00	$0.01	233
$340.00	$0.002	32
$302.40	$0.001	27
$276.37	$0.001	27

All four were re-read from Base's public node by transaction receipt; the USDC transfer to the seller carries exactly these amounts.

What it is, and what it is not

It is the on-chain shape of the flaw: a client that signs the amount it is asked for. It is also the shape of tiered or usage-based pricing, and the chain cannot tell the two apart. Read these as the ceiling of what the overcharge vector could have been on Base in those twelve days, not as a count of overcharges.

The payer side points the same way. Over 30 days the 25 cases come from 13 payers; none of them is an ERC-8004-bound agent wallet; ten of the thirteen made only one or two settlements in the whole month. The large cases look like single purchases, not an agent in a loop.

What it does establish: payments far above a seller's usual price settle on mainnet in the normal course of business, and a per-payment cap does not see them. A $1 cap lets a tenfold overcharge of a cheap resource through without a trace. The control that would have had something to act on is a caller-side price expectation.

If you run an x402 client

1. Upgrade to @x402/fetch / @x402/axios 2.23.0 or later (2.28.0 as of 23 Oct); apps using SIWx also need @x402/extensions 2.23.0+.
2. Set maxAmountPerPayment at the price you expect to pay, not at a round number.
3. Use the onBeforePaymentCreation hook to compare amount, payTo, network and asset in the 402 with the quote you accepted, and refuse when they differ (x402-foundation/x402#3866 has the discussion and fixtures).
4. Never pass spendControls: false in production.

Where the series lives

We publish the count every day as x402_settle_oversize_7d (and x402_settle_oversize_usd_7d): definition, per-settlement list, free, CC BY 4.0. We posted the figures in x402#3866 so the people fixing the client have mainnet numbers next to their fixtures.

This is how we intend to treat every disclosed flaw in an agent-payment rail: write the on-chain shape, measure it two ways, publish the series, keep publishing after the news moves on. Witness, not police; the client decides.