AI agents using the x402 payment SDKs could have signed away their entire wallet balance if a malicious API requested it, according to security firm V12 in a disclosure published October 22. The vulnerability stemmed from the SDKs' default client, which imposed no spending cap until updates released August 18 added one. The flaw affected only agents that automatically approved payments and whose applications hadn't set their own limits. V12 identified this missing limit as one of 25 vulnerabilities in the x402 codebase, and one of three it classified as critical and detailed publicly.
The x402 Foundation, which oversees the SDKs, had already patched all three critical flaws in the August 18 updates. A second critical bug allowed a facilitator—the service responsible for verifying x402 payments—to accept a Solana transaction that transferred zero tokens as legitimate payment. This flaw appeared only in the TypeScript SDK. The third let a hostile server trick an agent into signing a login message intended for a different website. V12 uncovered the vulnerabilities through code review and local testing, and neither the research firm nor the x402 Foundation has publicly confirmed any exploits in the wild. The foundation hasn't issued a security advisory for the three flaws, and its changelogs describe the fixes without labeling them as security patches. As of October 23, npm audit showed no warnings for the final TypeScript releases before the fixes, and PyPI listed no vulnerabilities for the last Python release preceding them, meaning developers relying on those tools receive no alert to upgrade.
According to V12, the default x402 client selected the first payment option a server provided, and before the fix, it placed no ceiling on the transaction amount. A malicious API could exploit this to convert a standard data request into a demand for the wallet's complete balance of a supported token. An earlier small payment might expose the wallet address, enabling the server to check the balance beforehand. With an automatic signing mechanism and no payment policy configured by the application, the client could authorize a payment for that full amount. For tokens supporting signed transfers, the attacker could then submit the signed payment and claim the funds. The August 18 releases introduced spending controls to the TypeScript, Python, and Go clients, which now default to a $1 cap per payment and permit only recognized U.S. dollar stablecoins such as USDC. The TypeScript facilitator code for Solana verified that a payment invoked an approved token program, then interpreted it as a transfer without confirming the instruction type. A token approval—which authorizes another account to spend tokens later but moves none immediately—differs from a transfer only in its opening byte. In V12's local test, the facilitator accepted such an approval as valid payment, though the test didn't broadcast a live transaction.
Coinbase built x402 and transferred it to the x402 Foundation this year, a Linux Foundation initiative whose members include Visa and Mastercard. Coinbase occupies the most senior position on the foundation's technical steering committee. The x402 standard is an open protocol that enables software, including AI agents, to pay for an API call within the web request itself, eliminating the need for manual approval of each transaction. A server requesting payment responds with HTTP status code 402 Payment Required and specifies its payment options, each listing an amount, token, and recipient. For the login vulnerability, the x402 sign-in extension Sign-In-With-X (SIWx) lets an agent authenticate by signing a brief message with its wallet, for instance to verify an earlier payment rather than paying again. On Ethereum, the message includes the website, wallet address, and a single-use code. The automated client signed these messages without confirming that the website named in them matched the one it had contacted, V12 found. A malicious server could retrieve a fresh login message from another site, relay it to the agent, and use the signature to authenticate to that site as the agent's wallet, gaining whatever access the login permitted. The August 18 releases make the TypeScript, Python, and Go clients reject any signing attempt unless the site in the message aligns with the site that issued the 402 response, and the project amended the SIWx specification to require clients to refuse signing when the two don't match.
V12 recommends that clients verify a SIWx login message identifies the site they contacted before signing, establish budgets for individual payments and overall spending, and restrict which tokens, networks, and recipients they'll pay. Upgrading to the latest releases also incorporates subsequent fixes, including one for a separate payment bypass in @x402/core 2.27.0 issued in September. As of October 23, the current versions are 2.28.0 for @x402/core, @x402/svm, @x402/extensions, @x402/fetch, and @x402/axios, v2.28.0 for the Go module, and 2.25.0 for the Python package. After upgrading, existing clients default to a $1 payment cap and accepted stablecoins only, unless the application configures its own spending controls—though applications passing spendControls: false disable all these protections. Teams unable to upgrade immediately can register a payment policy that rejects any option exceeding a specified amount, supported in older clients through registerPolicy in TypeScript and Go and register_policy in Python. The disclosure underscores the fragility of automated payment systems when default configurations assume trusted counterparties, a gap that widens as autonomous agents handle real financial transactions without human oversight. The absence of public advisories or automated tooling alerts means the burden falls entirely on development teams to monitor changelogs and self-assess exposure, a model poorly suited to the pace at which agent-based commerce is scaling.