Critical x402 SDK Flaw Could Let Malicious APIs Drain AI Agent Wallets

Security firm V12 disclosed on October 22 a critical flaw in the x402 SDKs, a framework that lets AI agents autonomously pay for API calls using supported tokens. The issue stemmed from the SDKs’ default payment client, which imposed no spending limit on transactions until a fix was released on August 18.

According to V12, a malicious or compromised API endpoint could exploit the unbounded default client by simply requesting payment for an AI agent’s entire token balance. If the agent’s application had no additional safeguards in place, it could sign and execute that payment automatically, draining its full balance to the attacker.

Who Was at Risk

V12 noted the exposure was limited to a specific set of conditions. Agents needed to be configured to automatically sign payments without human review, and their host applications needed to rely on the SDK’s default client without implementing their own spending caps or transaction limits. Agents using custom payment logic with built in restrictions were not affected in the same way.

The Fix

The vendor addressed the issue in SDK releases dated August 18, which introduced a default spending limit absent from earlier versions. Organizations still running pre-August SDK builds, or that have not verified their deployment includes the patched default client, remain exposed to the full-balance drain scenario described by V12.

Why It Matters

The disclosure highlights a broader risk category emerging as AI agents are given autonomous control over financial resources such as token balances and payment credentials. Default configurations that prioritize frictionless automation over conservative spending controls can turn a single malicious API response into a total loss of funds, with no human in the loop to catch the anomaly before execution.

Security teams building or deploying AI agents that interact with x402 or similar agent-to-API payment protocols should confirm they are running patched SDK versions, enforce explicit spending limits independent of SDK defaults, and consider requiring human approval for high-value or unusual payment requests.