The report
V12's October 22 technical report documents 25 weaknesses in x402 clients and facilitators, three described as critical. The first let an attacker-controlled service request excessive token transfers when a wallet signed payment requirements automatically without a configured limit. The second lacked an origin binding in an Ethereum sign-in challenge; the third accepted a Solana approval instruction as if it proved a token payment. V12 tested the validation bypass locally, rather than presenting an on-chain financial loss.
Corresponding fixes began shipping in August 2026, including spending defaults and stricter origin and instruction checking, so publication date is not patch date. The affected client, chain and version matter: the Solana bug does not become an Ethereum smart-contract vulnerability by association. A $1 default per-payment limit reduces a single-request exposure but does not independently enforce a complete lifetime wallet budget. No active exploitation or production loss is established by the cited research. Technical disclosure.
Three affected trust boundaries and the patch timeline
The vulnerable Solana facilitator parsed the instruction in a fixed position without checking the opcode, so ApproveChecked (0x0d) could be interpreted as TransferChecked (0x0c) in a local test. The Ethereum-oriented sign-in flaw instead concerned which domain a signature authenticated; the automatic-payment issue concerned who chose the amount and recipient before signing. V12 says the three critical findings were privately reported August 12 and fixed by August 20, ahead of the October 22 article. Its additional nine medium/low findings were submitted September 9, so the disclosed total of 25 is not the number of critical issues. No verified financial loss follows from these counts. Researcher disclosure timeline.
One protocol, three failed checks
| Adversarial control | Vulnerable decision | Directly demonstrated result |
|---|---|---|
| A merchant chooses a payment quote | The client signs an amount without a mandatory local spend budget | A wallet-drain path for an automatically signing client; no reported production loss |
| A server relays a challenge from another origin | The client signs without binding domain and URI to the contacted site | A valid cross-origin login signature in the research scenario |
| A buyer supplies a Solana token-program instruction | The facilitator parses an approval as a transfer without checking the discriminator | Local verifier acceptance despite no actual token movement |
V12 privately reported the three critical issues on August 12 and says they were fixed by August 20, well before the October 22 write-up. The three individual Case dossiers preserve their chain, actor and effect differences; none is evidence of a universal protocol-level wallet exploit. V12's reproduction and disclosure chronology.