- Security firm V12 found 25 flaws in x402's code, including a default client with no spending limit. The risk applied to agents that signed automatically in apps that set no limits.
- The x402 Foundation fixed the three critical flaws in August 18 releases, but The Hacker News found no security advisory, so npm audit and PyPI show no warning for older versions.
- Teams using x402 should check SDK versions by hand, confirm who sets spending limits, and review how much value sits in wallets that agents can sign for.
Who writes the invoice when software pays
Picture a company card with no spending limit, where each vendor decides what to charge. No finance team would sign off on that design.
Security firm V12 reviewed the code behind x402, a payment standard for AI agents, and found 25 vulnerabilities. It rated three as critical. One sat in the default client setup, which V12 says had no per-payment limit and no total budget. A server could ask for a wallet's whole balance of a compatible token.
Scope matters here. The Hacker News reports that the risk applied to agents that signed payments automatically in apps that set no limits. Releases on August 18 added a limit.
The lesson is that when software pays, the seller writes the invoice. The buyer's software has to hold the budget.
How x402 payments work
With x402, payment happens inside the web request itself. No person approves each step. V12 describes the flow. A server replies with the status code 402 Payment Required and lists the amount, token, network and recipient. The client signs a payment and repeats the request. A facilitator, a service that checks and submits payments, verifies it.
That suits AI agents that buy data on their own. It also means a server the agent has never met supplies the numbers the agent signs.
According to The Hacker News, Coinbase created the standard. This year it moved to the x402 Foundation, a Linux Foundation project whose members include Visa and Mastercard.
Three failures at three trust boundaries
V12 says each critical flaw crossed a different boundary: what counts as a payment, which website a signature is for, and who decides how much a wallet may spend.
First, payment. The TypeScript Solana facilitator confirmed a transaction called an allowed token program. It then read the transaction as a transfer without checking that it was one. Two Solana instructions share the same data layout and differ only in their first byte. One approves future spending. The other moves tokens. V12 says its local test accepted an approval as a valid payment, so a merchant could deliver goods and receive nothing. The facilitator would also pay the transaction fee. The Hacker News reports that only the TypeScript SDK had this flaw.
Second, identity. The Sign-In-With-X extension lets a wallet log in to a site. V12 found that the automatic wrapper signed login messages from a 402 response without checking that they named the site the client had contacted. A server run by an attacker could relay a login challenge from another site, collect the signature, and log in as that wallet. V12 describes the impact as session takeover wherever the target accepted such a relayed challenge.
Third, spending. V12 says the documented default client applied no spending policy and took the first payment option offered. The server supplied the amount. With an automatic signer and no policy from the application, the client could sign for the wallet's full balance of a compatible token.
The server could also learn the balance first. V12 says a small earlier purchase could reveal the wallet address, which the server could then look up before choosing an amount.
These findings come from code review and local tests. V12 did not submit live transactions. V12 also sells a security agent, so readers should weigh its framing with that in mind.
Fixes shipped without a security advisory
V12 sent the x402 team its report of 3 critical and 13 high-severity findings on August 12, 2026. It says the critical ones were fixed by August 20. It submitted 9 medium and low findings on September 9. The Hacker News reports that the foundation shipped the critical fixes in releases on August 18.
The sources do not report the status of the other 22 findings. That covers the 13 high-severity ones and the 9 submitted in September.
The Hacker News reports no public attacks using these flaws, from either V12 or the foundation.
The harder problem is notice. The foundation has issued no security advisory for the three flaws, The Hacker News found. Its changelogs do not label the changes as security-related. When the outlet ran the checks on October 23, the older TypeScript packages passed npm audit cleanly. The older Python package carried no PyPI vulnerability listing. A team relying on those tools receives no prompt to upgrade.
The new TypeScript, Python and Go clients ship with spending controls, The Hacker News reports. Each payment is capped at $1 by default. The defaults also narrow payment to dollar-backed stablecoins on the SDK's recognized list. USDC is one example.
What to ask your team
Start by asking whether any agent or service uses x402. If so, ask for the SDK versions in use and compare them with the August 18 releases by hand. Automated audits would not flag the older ones.
Then ask who sets the limits. V12 says clients should enforce explicit per-payment and total budgets, plus permitted tokens, networks and recipients. It adds that optional policies only protect applications that enable them.
Ask how much value sits in any wallet an agent can sign for. Ask whether signing is automatic or needs approval. If you run a Solana facilitator on the TypeScript SDK, confirm it checks the instruction type.
Agents that spend money need the same controls as staff who spend money. Limits belong on the buyer's side, and the seller's price should not be the only number in the transaction.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: V12.
