#0x5F

TOCTOU Attack Allows Wallet Drain via Transaction Simulation Spoofing

@purgesubmitted a report toJupiterMay 22, 2026 at 07:52

Severity	INFORMATIONAL
CVSS	6.8`CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:H`
Vulnerability Type	Time-of-Check to Time-of-Use (TOCTOU)
Asset	jupiter-mobile-solana-wallet - Jupiter Mobile iOS App

Description

TOCTOU Vulnerability in Jupiter Mobile & Wallet Extension Due to Missing Execution-Time Assertion Checks

Jupiter Mobile (iOS, Android) and Jupiter Wallet Extension do not implement execution-time assertion checks on transactions, making them vulnerable to a Time-of-Check to Time-of-Use (TOCTOU) attack. This allows a malicious dApp to drain a user's wallet while the transaction simulation displays a positive balance change.

The root cause is the absence of Lighthouse (https://github.com/Jac0xb/lighthouse). For context, Phantom and Solflare mitigate this attack by implementing it.

When a user signs a transaction, Jupiter simulates the transaction against the current blockchain state (S₀) and displays the predicted outcome to the user. However, the actual execution occurs against a different state (S₁). If S₀ ≠ S₁, the simulation no longer reflects what will actually happen on-chain.

An attacker can deliberately engineer this state difference using Jito bundles, causing the wallet to display "+1 SOL, +500 USDC" (or any positive outcome) while the executed transaction drains the user's entire wallet. The user does everything correctly: they check the simulation, see a favorable outcome, and sign. They still lose all their funds.

This undermines the trust that users have in transaction simulation results.

Note: Since I could not attach videos for PoC, I attached some screenshots from the videos.

Mobile (iOS) test txid:
https://solscan.io/tx/VVMJyaMbHpiUSSuwTUNooVut9qfQbRfRP5HD9Zj3jRDfZSxTQ2fBWTxkdorG9Zc782BZG6oxGnD1sE1PEvc5GpW

Extension test txid:
https://solscan.io/tx/2thfMgBMhBTFNqgc6PaPCbVBY8XU3VSie4qL43TVxk4KiZTeNYWKgQsN8f7jUsvxUbDya4XLeobXeNZBvM3C4V1q

Steps to Reproduce

Prerequisites

Deploy a Solana smart contract with conditional logic that checks whether a PDA account is empty or non-empty, executing different code paths based on this check. The benign path credits the user funds; the malicious path drains their wallet.
Set up a dApp frontend that connects to Jupiter and requests signTransaction (not signAndSendTransaction).
Set up a backend listener to receive the signed transaction blob.
Configure the backend to construct and submit Jito bundles.

Attack Flow

User connects their Jupiter wallet (iOS or Extension) to the malicious dApp.
User initiates a transaction through the dApp.
At simulation time (S₀), the smart contract checks the PDA account and finds it empty, so the benign branch executes during simulation.
Jupiter displays a positive balance change to the user (e.g., "+0.1 SOL").
User reviews the simulation, sees the positive outcome, and signs the transaction.
The signed transaction blob is sent to the attacker's backend instead of being broadcast.
The backend constructs a Jito bundle with the following transactions executed atomically:
- Tx1: Send a small amount of SOL to the derived PDA account (making it non-empty)
- Tx2: The user's signed transaction
- Tx3: Optionally close the PDA account
- Tx4: Jito tip
The bundle is submitted to Jito and executes atomically on-chain.
At execution time (S₁), the contract sees a non-empty PDA and executes the malicious drain branch instead.
The user's wallet is drained.

Additional Notes

I can provide contract code or other materials upon request.

Note: The vulnerability affects wallet behaviour and not Jupiter's smart contracts (to which the forked mainnet requirement applies). Wallet testing requires live Jito infrastructure and cannot be replicated on a fork. All testing was performed on accounts that I own. No third-party users or funds were affected.

Impact

A malicious dApp can present a Jupiter wallet user (Mobile/Extension) with a transaction showing a positive balance change, obtain their signature, and drain their wallet. The user follows all reasonable security practices, checks the simulation, and signs what appears to be a safe transaction. They still lose everything.

Any Jupiter wallet user who interacts with Solana dApps is at risk.

References (3)

https://github.com/Jac0xb/lighthouse

https://phantom.com/learn/blog/anti-spoofing-security

https://www.blockaid.io/blog/dissecting-toctou-attacks-how-wallet-drainers-exploit-solanas-transaction-timing

Attachments (6)

Activity

@thibaultclosed the report asInformative

May 22

@thibaultchanged the severity fromcriticaltoinformational

May 22

@raccoonsdisclosed this reportPublic Disclosure

May 22

Properties

Status

INFORMATIVE

Severity

INFORMATIONAL

Reporter

@purge

Program

Jupiter

Prerequisites

Deploy a Solana smart contract with conditional logic that checks whether a PDA account is empty or non-empty, executing different code paths based on this check. The benign path credits the user funds; the malicious path drains their wallet.
Set up a dApp frontend that connects to Jupiter and requests signTransaction (not signAndSendTransaction).
Set up a backend listener to receive the signed transaction blob.
Configure the backend to construct and submit Jito bundles.

Attack Flow

User connects their Jupiter wallet (iOS or Extension) to the malicious dApp.
User initiates a transaction through the dApp.
At simulation time (S₀), the smart contract checks the PDA account and finds it empty, so the benign branch executes during simulation.
Jupiter displays a positive balance change to the user (e.g., "+0.1 SOL").
User reviews the simulation, sees the positive outcome, and signs the transaction.
The signed transaction blob is sent to the attacker's backend instead of being broadcast.
The backend constructs a Jito bundle with the following transactions executed atomically:
- Tx1: Send a small amount of SOL to the derived PDA account (making it non-empty)
- Tx2: The user's signed transaction
- Tx3: Optionally close the PDA account
- Tx4: Jito tip
The bundle is submitted to Jito and executes atomically on-chain.
At execution time (S₁), the contract sees a non-empty PDA and executes the malicious drain branch instead.
The user's wallet is drained.

Additional Notes

I can provide contract code or other materials upon request.