Securityaiagentscryptopayments
x402, the HTTP 402 Payment Protocol for AI Agents, Shipped With No Spending Limit: V12 Found a Server Could Ask for the Whole Wallet
V12 found 25 flaws in the x402 payment SDKs AI agents use to buy API calls, three critical: no default spending cap, a Solana check that took a token approval as payment, and logins signed for the wrong site. The fixes shipped in August with no security advisory.
An AI agent asks a server for some data. The server answers “402 Payment Required” and names the price, the token, the network and who gets paid. Until August, the default x402 client took the first payment option it could handle and signed it.
That’s the finding Renwa of V12 laid out on October 22. “The documented default client setup did not enforce a per-payment limit or a total spending budget,” the write-up says. A hostile API could “turn a routine data request into a request for the wallet’s full balance of a compatible token.” A small first payment would even tell the server the wallet address, so it could look up the balance before naming its price.
The Solana bug is the one that looks like a magic trick. The TypeScript facilitator, the middleman that checks a payment before the merchant hands over the goods, confirmed the transaction called the right token program and then read the instruction as a transfer. It never checked the instruction type. ApproveChecked, which grants permission to spend and moves nothing, has the same layout as TransferChecked. The two differ only in the first byte, 0d against 0c. V12 calls it “a complete payment bypass”: the merchant ships, receives nothing, and the facilitator pays the transaction fee. Its test ran locally, and V12 says it did not submit a live transaction.
The third one is a relayed login. The Sign-In-With-X helper copied the site name and address straight from the server’s 402 response and signed them. A server the agent was buying data from could fetch a fresh login challenge from some other site, hand it to the agent, collect the signature and log in as the agent’s wallet. “The target site’s normal domain and signature checks would still pass,” V12 notes, because the signature is real.
V12 says it reported the critical and high findings on August 12 and the three criticals were fixed by August 20. The record on GitHub matches. The Solana check merged on August 12. The sign-in fix “require[s] SIWx challenge domain / uri” to match the 402 response’s origin, and the spend controls added “a default $1 USD cap on recognized pegged assets.” The TypeScript packages carrying all three, version 2.23.0 of @x402/fetch and friends, went out August 18.
The changelog files those changes as “Minor Changes” and never uses the word security. The project’s advisories page still ends at March. Anyone on an older release who runs npm audit today gets nothing back.
Payment code for agents is getting written at the speed of agent demos, and the security process around it is still catching up. Expect the next round of these to show up the same way: found by automated reviewers, fixed in a feature release, and noticed by everyone else weeks later.
The open question is how many agent wallets are still running a pre-August client with no budget set.