Security firm V12 says the default x402 payment client for AI agents set no spending limit, so a hostile API could have asked an auto-signing agent to pay its whole wallet balance

What happened

Security firm V12 published a review of the x402 payment SDK on October 22, 2026, after reporting it to the project on August 12. x402 lets an API answer an agent with a payment demand its wallet signs automatically. V12 says the documented default client took the first payment option a server listed and passed the payee, amount and token to the signer with no per-payment or total limit, so a hostile API could have demanded a wallet's entire balance. Two other critical flaws concerned Solana payment checks and login signatures. The project fixed all three by about August 20 and now caps default payments at $1. V12 says its tests were local, no funds moved and no attacks are known. How many deployments ran the unprotected default is unknown.

Why it was a problem

The server an agent contacted, which may be hostile, chose how much the agent would pay. The only protection was a spending policy that each application had to turn on, so applications that did not were exposed. A payment signed automatically leaves no point at which a person or a limit can intervene. The evidence is one firm's code review and local tests, supported by the project's own code changes. No exploitation is reported.

How SAG could have helped

Under the assumptions below, the agent's work would be a work class with one declared payment step whose fields are the payee, amount, token and network. The authority envelope, the human grant for that work, would list the payees and tokens the agent may pay and set a per-action limit, an upper bound on a single payment. A server that demands the wallet's full balance asks for an amount above that limit, so the payment would be refused before it was signed, and a payee or token outside the list would be refused the same way. A shared budget, a cumulative cap over a set period with a reservation taken before each payment, would stop many small payments from adding up past the total, even when several agents draw on one wallet. Permission attaches to the exact payee and amount a person granted, so a payment demand the agent receives from a server grants nothing. SAG does not detect a hostile API, fix the SDK's verification flaws, or recover funds already paid.

Assumptions we must make

• The organization defines the payment step with its payee, token and network fields, and a person grants the allowed payees and tokens, a per-payment cap and a total budget for the period. (Assumed)
• The wallet's signing key is usable only through the governed path, so no client library or second signer can authorize a payment outside it. Public reporting does not say how deployments held their keys. (Unknown)
• The host signs only the exact payee, amount, token and network that were permitted, and commits each decision and budget reservation before signing. (Assumed)

Classification

Category

Disclosed vulnerability

Section

Agent governance

Is update

No

Rank

2

Event date text

Reported to the project 2026-08-12; critical issues fixed by about 2026-08-20

Publication date text

2026-10-22 (V12); 2026-10-23 (The Hacker News)

Governance analysis

Intended task

Pay for API calls automatically when a server answers with an x402 payment demand.

Action taken or attempted

The default client selected the first listed payment option and passed the server's payee, amount, token and network to an auto-signing wallet. V12 showed this in local tests; no live payment was made.

Access

A wallet signer able to authorize token transfers, and the HTTP responses of any API the agent contacts.

Authority boundary

How much, in which token and to whom the agent may pay, versus whatever the contacted server demands.

Harm or near miss

Potential loss of a wallet's full balance of a compatible token. No funds moved and no exploitation is reported.

Control failure

The default client had no per-payment or total limit, took the server's first option, and left spending controls to an optional policy.

Control categories

Scope of authority, Action time authorization, Identity permissions

Diagnosis confidence

Confirmed

Preventive or detective control

Per-payment and total budgets, allowlists of recipients, tokens and networks, enforced before signing and on by default.

Timeline

• Reported to x402 team: 2026-08-12
• Spend controls released: 2026-08-18 (The Hacker News) or by 2026-08-20 (V12) (disputed)
• Further findings submitted: 2026-09-09
• V12 publication: 2026-10-22
• Hacker news coverage: 2026-10-23

Sources

• v12.sh
• thehackernews.com
• github.com

Notes

From sources

• The default client set no spending limit and took the first listed option (V12; The Hacker News).
• Default spend controls capping payments at $1 USD for recognized stablecoins were added in a pull request to the project (GitHub pull request 3124; The Hacker News).
• No exploitation has been publicly reported (V12; The Hacker News).

Inferred

• A per-action limit and payee and token allowlist would have refused a full-balance demand (supported inference from the described payment fields).

Not established

• How many deployments used the default without spend controls.
• Exact affected versions of the spend flaw; V12 does not list them.
• Whether any hostile API exploited this before the fix.
• Merge date of the spend-controls pull request.

Disclaimers

• The SAG section is an architectural counterfactual under the stated assumptions. It is not a claim that Seampoint software operated in the reported environment.
• Reporting is based on public statements and press coverage. Sources may be incomplete, disputed or later corrected, and third-party allegations are unconfirmed unless the operator confirms them.
• SAG is described here by reference to Seampoint's work-class specification, which is an open review draft. It is not an adopted standard, and no production deployment has been qualified against it.