A critical x402 SDK flaw could make AI agents sign a payment worth the entire balance of a token to a malicious API. Security firm V12 raised the alarm on October 22, according to The Hacker News. Not everyone was at risk. The flaw hit agents that signed payments automatically, in apps that had no spending limit set up.
First, what is x402? It is an open standard that lets software, including AI agents, pay for an API call inside the web request itself, with no person needing to approve each charge. Here is how it works: the server replies with HTTP status code 402, which means payment required, and lists the payment options. Each one shows an amount, a token and a recipient. The client picks one, signs it and sends the request again.
It is handy. But it needs brakes. And that is exactly what was missing, according to the report: the default client grabbed the first option on the list and, before the fix, set no cap on the amount. According to V12, a hostile API could turn a routine data request into a charge for the full wallet balance. A small earlier payment could even reveal the wallet address, letting the server check the balance before charging.
This was one of 25 issues V12 found in the x402 code, and one of the three the firm rated as critical. The other two also deserve attention, so let us walk through them.
The other two critical flaws
The second flaw involved the Solana network and only affected the TypeScript SDK. In x402, there is a service called the facilitator, which checks payments and sends them to the blockchain. On Solana, it also covers the transaction fee. According to the outlet, the TypeScript facilitator code did not check the type of instruction it received. As a result, a simple token approval, which moves no funds at all, could be accepted as a valid payment.
Receive the best innovation content in your email.
All the news, tips, trends, and resources you're looking for, delivered to your inbox.
By subscribing to the newsletter, you agree to receive communications from Método Viral. We are committed to always protecting and respecting your privacy.
In practice, a merchant could hand over paid content and get nothing in return. V12 described the problem as a full payment bypass. One key detail: this was shown in a local test, with no real transaction on the network. The Python and Go versions already ran this check.
The third flaw was in the SIWx login extension, which lets an agent identify itself by signing a short message with its wallet. The automated client signed these messages without checking whether the site named in them matched the one it had actually visited. So, according to V12, a malicious server could pass the agent a login message from another site and use the signature to log in there as if it were the wallet of the agent.
The good news is that all three critical flaws had already been fixed in the versions released on August 18. According to The Hacker News, neither V12 nor the x402 Foundation has publicly reported any attacks using these gaps. The standard was created by Coinbase and handed over this year to the foundation, a Linux Foundation project with Visa and Mastercard among its members.
The detail that worries developers
If the fix came out in August, why is this only surfacing now? Because the warning barely got out. The foundation did not publish a security advisory about the three flaws. The changelogs for the new versions mention the fixes, but do not flag them as security issues.
There is more. According to The Hacker News, on October 23 npm audit showed no alerts for the latest TypeScript versions released before the fixes. On PyPI, the last Python version before the patch also showed no listed vulnerabilities.
In other words, anyone who relies only on these tools to know when to update gets no signal at all. A project can keep running a vulnerable version without anyone on the team noticing.
What changes for those automating payments in Brazil
Step one is to update. In TypeScript, the spending limit fix ships with the @x402/fetch or @x402/axios packages at version 2.23.0 or higher. Anyone using SIWx login also needs @x402/extensions at 2.23.0 or later. And anyone verifying payments on Solana needs @x402/svm at that same version or above.
Jumping straight to the latest version also brings later fixes. According to the outlet, that includes a fix for another payment bypass, patched in September in @x402/core 2.27.0. As of October 23, the newest versions were 2.28.0 for the TypeScript packages and the Go module, and 2.25.0 for the Python package.
After updating, according to the report, each payment is capped at 1 dollar, and the client only accepts dollar stablecoins recognized by the SDK, such as USDC. This holds until the app sets its own controls.
Here is the catch. If the code turns off the spending controls, all of that protection disappears at once. So it pays to review the setup carefully, especially in inherited projects or ones built in a rush.
What if you cannot update yet? You can register a payment policy that drops any option above a set amount. According to the outlet, older versions already support this feature in TypeScript, Go and Python.
The bigger lesson on AI agent security
This case goes beyond one SDK. Giving an agent the power to pay is, in practice, handing it a wallet. The V12 recommendations, as reported by the outlet, apply to any similar project:
- set one budget per payment and another for total spending;
- limit which tokens, networks and recipients the agent can pay;
- check that the site named in a login message matches the one the agent visited before signing.
This ties into what we have already covered on layered security for autonomous agents: no single safeguard is enough, and the safest approach is to combine limits, permissions and checks.
For anyone testing payments with AI agents in digital products, marketing campaigns or day-to-day operations, the message is clear. Payment automation is not something to sort out later. Picture a small business that sets up an agent to buy data from an API, leaves automatic signing on and skips the spending cap. With a vulnerable client, a single malicious request could wipe out the balance of a token in the wallet. It is the kind of slip that helps explain why AI automation fails in so many businesses.
So far, there is no public record of attacks exploiting these flaws. Even so, checking versions and limits today costs far less than finding the problem on your wallet statement. If you want to dig deeper, you will find more context in our piece on autonomy, security and transparency in AI agents.
