A facilitator should confirm that a signed transaction actually transfers the expected tokens. V12 found that a parser could decode an ApproveChecked instruction as a TransferChecked instruction because the data layout overlapped and the instruction type byte was not enforced. An attacker could provide a transaction that authorizes a delegate but sends no…
Inspect the ClaimsCase · DiggingBeagle record
x402 Solana facilitator parsed token approval as a paid transfer
The TypeScript Solana facilitator did not verify the token-instruction discriminator before accepting a parseable instruction as a transfer, enabling local payment-verification bypass.
Scope
Solana token-program x402 TypeScript facilitator; exact schemes v1 and v2.
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-SOLANA-APPROVAL-AS-PAYMENT: A locally constructed ApproveChecked instruction was parsed as TransferChecked, allowing verification to pass without a token transfer in V12 testing. 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-SOLANA-01 · V12: 25 x402 vulnerabilities and three critical mechanisms
At a glance
The vulnerability harms a seller or resource provider by accepting an unpaid request, rather than draining an agent wallet. V12’s reproduction was local and did not prove fraudulent resource delivery on-chain or in a production facilitator.
Read the implicationsNo chain transaction or service-access fraud in production is documented.
Limits and uncertaintyFull account
A facilitator should confirm that a signed transaction actually transfers the expected tokens. V12 found that a parser could decode an ApproveChecked instruction as a TransferChecked instruction because the data layout overlapped and the instruction type byte was not enforced. An attacker could provide a transaction that authorizes a delegate but sends no funds, yet the facilitator treats it as a completed payment. V12 reproduced this in a local test, without broadcasting a malicious transaction or establishing merchant losses. The flaw concerns payment verification on Solana, not EVM execution, and is distinct from the missing spending cap that could harm a buyer. The documented remediation is to validate the instruction type before accepting payment proof.
In the observed local test, the facilitator accepted proof with the right program and compatible fields but the wrong token instruction. ApproveChecked authorizes a delegate, while TransferChecked moves the specified funds; overlapping layouts cannot establish equivalent payment semantics. The reported successful verification therefore speaks to a seller-side resource-release decision, not a buyer wallet being drained or a real merchant losing money. V12 reported the critical finding privately on August 12, says it was fixed by August 20, and described the local test on October 22. Researcher disclosure.
Mechanism and trust boundary
- 01
Prepare a Solana payment-proof instruction
A malicious buyer constructs an instruction whose data fields resemble the expected checked token transfer.
Boundary: Buyer transaction data / facilitator verification
- 02
Substitute ApproveChecked for TransferChecked
The v1/v2 exact facilitator parsed the third token instruction without validating the opcode; token approval and token transfer shared the relevant data layout.
Boundary: Instruction discriminator / payment semantics
- 03
Pass a local check without moving funds
The verifier can treat approval as payment even though no merchant token transfer occurred in the researcher’s local reproduction.
Boundary: Syntactic transaction parse / economically settled transfer
Timeline
- Aug 12, 2026Event type unspecified
Researchers privately report the critical x402 issue
V12 says this vulnerability was reported to maintainers with two other critical findings.
- Aug 20, 2026Event type unspecified
Critical-finding fixes completed
V12 dates completion of fixes for the three critical findings by August 20, ahead of their public report.
- Oct 22, 2026Event type unspecified
Solana proof-validation bypass publicly described
V12 separated this merchant-side verification defect from buyer-side payment authorization and wallet login defects.
- Oct 22, 2026disclosure
Public disclosure
Claims & evidence
CLM-X402-SOLANA-01A locally constructed ApproveChecked instruction was parsed as TransferChecked, allowing verification to pass without a token transfer in V12 testing.supported
Basis: reported finding
- supportsV12: 25 x402 vulnerabilities and three critical mechanismsprimary disclosure
An approval was accepted as a payment, without transferring funds
CLM-X402-SOLANA-ENRICH-OPCODEApproveChecked (0x0d) and TransferChecked (0x0c) share compatible layouts; the vulnerable parser skipped the discriminator, and V12 locally obtained an accepted payment result without a transfer.supported
Basis: reported finding
- supportsV12: 25 x402 vulnerabilities and three critical mechanismsprimary disclosure
An approval was accepted as a payment: first-byte comparison and local verification
Implications
The vulnerability harms a seller or resource provider by accepting an unpaid request, rather than draining an agent wallet. V12’s reproduction was local and did not prove fraudulent resource delivery on-chain or in a production facilitator.
Controls and mitigations
- Use x402 Solana components with the instruction-type validation fix; verify token-program ID, instruction discriminator, actual account debits and credited destination rather than interpreting parseable fields as settlement.
Unknowns and contradictions
- No chain transaction or service-access fraud in production is documented.
Sources and citation
Material revision history
- Oct 24, 2026 · Canonical change recorded · new in release · revision 188