Evidence · DiggingBeagle record
V12: 25 x402 vulnerabilities and three critical mechanisms
October 22 technical disclosure of spending authorization, cross-origin SIWE and Solana payment-verification flaws, with explicit limits of local testing.
- Source role
- primary disclosure
Evidence record
October 22 technical disclosure of spending authorization, cross-origin SIWE and Solana payment-verification flaws, with explicit limits of local testing.
Claim-level citations (7)
- supportsx402 automatic signers accepted merchant-controlled spending amounts: The documented client selector passed a server-supplied payment amount, token, network and recipient toward a signing call without a mandatory spend policy.
Default client setup had no spending limit
- supportsx402 automatic signers accepted merchant-controlled spending amounts: V12 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.
Default client setup had no spending limit; Disclosure and fixes
- supportsx402 automatic signers accepted merchant-controlled spending amounts: The exploit requires an automatic signer without an overriding application or wallet policy; V12 did not report confirmed production wallet draining.
Default client setup had no spending limit; Conclusion
- supportsx402 sign-in extension could relay a cross-origin wallet login signature: The SIWE client signed a formatted login challenge for an origin other than the service contacted, without checking the domain and URI against that server.
A server could request a login signature for another website
- supportsx402 sign-in extension could relay a cross-origin wallet login signature: V12 demonstrated a correctly formatted SIWE signature whose domain was unrelated to the contacted host and identified origin binding as the missing client-side check.
A server could request a login signature for another website
- supportsx402 Solana facilitator parsed token approval as a paid transfer: A locally constructed ApproveChecked instruction was parsed as TransferChecked, allowing verification to pass without a token transfer in V12 testing.
An approval was accepted as a payment, without transferring funds
- supportsx402 Solana facilitator parsed token approval as a paid transfer: ApproveChecked (0x0d) and TransferChecked (0x0c) share compatible layouts; the vulnerable parser skipped the discriminator, and V12 locally obtained an accepted payment result without a transfer.
An approval was accepted as a payment: first-byte comparison and local verification