A data request becomes a payment decision when an API returns HTTP 402 and an agent signs the response requirements. In V12's source examination, the default selection path chose the first supported option without enforcing a budget. A malicious data provider could choose a recipient and an amount matching the signer's supported-token balance. Because the…
Inspect the ClaimsCase · DiggingBeagle record
x402 automatic signers accepted merchant-controlled spending amounts
V12 found the documented default x402 client path lacked a per-payment cap or total spending budget. A hostile API could request most or all of a supported token balance when an automatic signer accepted its payment requirements.
Scope
Client-side x402 default payment selection and EVM-compatible token authorization; report dated October 22, fixes applied by August 20.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- fixed reported
- AI role
- AGAINST AI
Basis and provenance
CASE-2026-X402-AUTOSIGN-SPEND-BOUNDARY: Default maximum unspecified before the fix; vendor patch defaults to a $1 payment cap; no measured production loss. Evidence comes from SRC-2026-V12-X402-25-FINDINGS. Published technical statements or controlled results are not verified production-loss counts. No impact band is assigned because the observed outcome and its denominator do not establish a comparable severity measure.
Assessed Oct 24, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-X402-SPEND-01 · V12: 25 x402 vulnerabilities and three critical mechanisms
At a glance
A $1 per-payment SDK cap reduces maximum loss from a single signed request but does not enforce daily/cumulative budgets, recipient allowlists or user-approved purpose. Unauthorized wallet value is a possible consequence from vulnerable defaults, not a measured production theft total.
Read the implicationsNo verified unauthorized production signatures or wallet losses were supplied. Downstream wrappers may impose their own wallet-policy limits.
Limits and uncertaintyFull account
A data request becomes a payment decision when an API returns HTTP 402 and an agent signs the response requirements. In V12's source examination, the default selection path chose the first supported option without enforcing a budget. A malicious data provider could choose a recipient and an amount matching the signer's supported-token balance. Because the wallet signs a cryptographic authorization, this is an action-boundary failure rather than an EVM smart-contract flaw. The issue was reported to maintainers on August 12 and fixed by August 20, before the public October 22 disclosure. An explicit $1 per-payment cap was added in an SDK fix, but application-wide spending and recipient policy remain separate controls. V12 did not report a production victim or confirmed theft. The relevant metric is the missing default limit, not observed dollars stolen.
Mechanism and trust boundary
- 01
Ask an API for data
The external merchant sends HTTP 402 payment requirements naming an amount, asset, network and recipient.
Boundary: External resource server / wallet spending requirements
- 02
Use the first acceptable quote without local limits
The default client selector may pass the server’s amounts into the signing flow when no application-owned spend policy is enabled.
Boundary: Merchant-authored payment details / wallet authorization
- 03
Sign a potentially balance-sized transfer
A hostile merchant could select a supported token amount comparable to the wallet balance; exposure depends on signer capabilities and any external wallet guardrails.
Boundary: Automatic signing action / irreversible asset transfer
Timeline
- Aug 12, 2026Event type unspecified
Critical issues privately reported
V12 reported three critical findings to protocol maintainers.
- Aug 20, 2026Event type unspecified
Critical fixes completed
V12 dates completion of fixes for all three critical findings by this date.
- Oct 22, 2026Event type unspecified
Technical public disclosure
The researcher published the three distinct mechanisms.
- Oct 22, 2026disclosure
Public disclosure
Claims & evidence
CLM-X402-SPEND-01The documented client selector passed a server-supplied payment amount, token, network and recipient toward a signing call without a mandatory spend policy.supported
Basis: reported finding
- supportsV12: 25 x402 vulnerabilities and three critical mechanismsprimary disclosure
Default client setup had no spending limit
CLM-X402-SPEND-ENRICH-FIXV12 said the documented default client had neither per-payment nor total spending limits; the researcher reported the three critical x402 issues August 12, and fixes were completed by August 20.supported
Basis: reported finding
- supportsV12: 25 x402 vulnerabilities and three critical mechanismsprimary disclosure
Default client setup had no spending limit; Disclosure and fixes
CLM-X402-SPEND-ENRICH-PREREQThe exploit requires an automatic signer without an overriding application or wallet policy; V12 did not report confirmed production wallet draining.supported
Basis: reported finding
- supportsV12: 25 x402 vulnerabilities and three critical mechanismsprimary disclosure
Default client setup had no spending limit; Conclusion
Implications
A $1 per-payment SDK cap reduces maximum loss from a single signed request but does not enforce daily/cumulative budgets, recipient allowlists or user-approved purpose. Unauthorized wallet value is a possible consequence from vulnerable defaults, not a measured production theft total.
Controls and mitigations
- Upgrade the SDK and enforce application-owned per-payment and cumulative budgets, allowed assets, networks, recipients and signer privileges. Reject over-budget requests before any signature is produced.
Unknowns and contradictions
- No verified unauthorized production signatures or wallet losses were supplied.
- Downstream wrappers may impose their own wallet-policy limits.
Sources and citation
Material revision history
- Oct 24, 2026 · Canonical change recorded · new in release · revision 187