Imagine walking into a store, making a purchase, and leaving—only to realize later that you were charged 100 times more than what the checkout screen showed you. 

This is essentially what happens when users fall victim to time-of-check-time-of-use (TOCTOU) attacks, a new attack vector used by Solana drainers.

Here’s how these TOCTOU attacks work, why they’re difficult to detect, and what users can do to protect themselves from these silent threats.

What is a TOCTOU attack?

A time-of-check-time-of-use (TOCTOU) attack is a type of exploit that takes advantage of the gap between when a system verifies something and when it acts on that verification. 

It’s a classic cybersecurity vulnerability that has made its way into the blockchain world.

Think of it like entering a club that requires everyone to wear hats. If the security guard only checks for hats at the start of the queue, people could simply wear a hat to get past the check and then take it off as soon as they enter the club, walking around hat-free. 

In a TOCTOU attack, the system checks if everything is in order at the start (in our example, checking for hats), but by the time the action takes place (entering the club), the conditions have changed, and the system doesn’t notice.

TOCTOU in Web3 - Attacking Transaction Simulation

In the world of Web3, TOCTOU attacks operate in much the same way, but with a new target: transaction simulation. 

Many wallets and dApps integrate simulations as part of their security measures, allowing users to preview the potential outcome of a transaction before they sign it. 

These simulations provide an added layer of protection by identifying potential threats and verifying the transaction’s behavior based on the current state of the blockchain.

However, TOCTOU attacks exploit the gap between the simulation (when the transaction is checked) and the actual execution on-chain. 

During this brief window, attackers manipulate the on-chain state, causing the transaction to result in a different outcome than what was shown in the simulation.

For example, a transaction that appears to send tokens to a legitimate address during simulation may, due to changes in the on-chain state, end up draining the user’s wallet. 

Since users rely on simulations to confirm the safety of transactions, this manipulation creates a false sense of security, leaving them vulnerable to malicious activity that goes undetected.

TOCTOU attacks in Solana

This issue is even more severe in Solana due to its unique runtime architecture.

When a user signs a transaction, they grant permission for every program involved to modify writable accounts without restrictions.

As a result, any account in the transaction can potentially drain the user’s SOL or SPL tokens.

This flexibility in Solana’s design makes its security far more reliant on accurate transaction simulations - and indeed, as Solana’s popularity grew, wallet drainers began using TOCTOU attacks to exploit this gap, bypassing simulations and manipulating transactions undetected.

During these attacks, the wallet simulation reveals a completely benign outcome. However, once the user signs the transaction, the outcome completely changes. 

As a result, the attacker can drain the user’s assets without being flagged during the simulation, rendering the security check ineffective.

The anatomy of a TOCTOU attack on Solana

1. Deploy the malicious program
   • The attacker deploys a malicious program with TOCTOU logic, designed to pass unnoticed during simulation. The program typically lacks visible source code references or Anchor IDL, making it difficult to detect.
2. Spoof transaction simulation with false data
   • When the user initiates a transaction, their wallet runs a simulation to verify its safety. During this phase, everything appears legitimate—the program doesn’t trigger any red flags, and the transaction seems to behave as expected. The malicious state remains inactive during the simulation, creating a false sense of security.
3. Change the state after signature
   • Once the user signs the transaction, the attacker, who controls the dApp and now holds the signed transaction, alters the state of the program, activating a malicious flow. The attacker then sends the manipulated transaction to be executed on-chain.
4. Execute and drain assets
   • By the time the transaction is executed on-chain, it behaves completely differently than it did during the simulation. Instead of performing the intended action, the transaction drains the user’s assets, redirecting them to the attacker’s wallet. At this point, the user has no way to stop or reverse the transaction.

Real-world example: a Solana TOCTOU attack in action

To better understand how TOCTOU attacks unfold in the real world, let’s look at a specific example involving Vanish Drainer, one of the many drainers that Blockaid tracks. 

In this case, the attacker used a malicious program that altered the transaction state after it was signed but before it was executed, allowing them to drain the victim’s assets.

Here’s how the attack unfolded:

The program

The attacker deployed a program (you can see it here - it’s now inactive) designed to appear harmless during simulation. 

The program contained a hidden state condition that wasn’t triggered during the simulation, allowing it to pass without raising any security flags.

In this program, the state (which determined whether the program should execute the malicious flow or not) was represented by the existence of a token account with the mint CPMbUt3SSoeoCJGCzhqmy7ZoaHWqd8AQPTvYiNeSxatt.

Since this condition wasn’t triggered during the simulation, the transaction passed all checks.

State change trigger 

Once the user’s signature was secured, the attacker’s infrastructure issued a transaction that set the state and activated the malicious flow. 

This transaction was executed before the user’s transaction—because the attacker also controlled the dApp. 

The transaction 

After setting the malicious state, the attacker executed the user’s signed transaction, which drained approximately $3,000 worth of tokens from the user’s wallet. 

Notably, the user’s transaction was executed on block 247363977, just seven blocks after the attacker’s state-setting transaction (which was executed on block 247363970).

The short time window between the state change and the asset drain—just a few seconds—demonstrates how quick and efficient these attacks can be on Solana’s high-speed network, leaving little opportunity for detection.

Why TOCTOU attacks are so hard to detect

Many wallets and dApps rely heavily on transaction simulations to analyze a transaction's behavior based on the state of the blockchain at the time the simulation is run. 

 However, these simulations do not account for any state changes that can occur between signing and execution. 

This is the critical gap that TOCTOU attackers exploit—manipulating the transaction state after the simulation has passed but before the transaction is processed on-chain.

This kind of attack reveals a fundamental limitation of traditional simulations: they cannot anticipate future changes in the program’s behavior. 

As a result, even transactions that appear perfectly safe during the simulation can be compromised later.

These attacks serve as a clear reminder that simulations alone are not enough for ensuring security in blockchain environments. 

While they are an important tool, advanced techniques such as real-time state monitoring or deeper transaction analysis are necessary to protect against threats like TOCTOU attacks.

How to mitigate TOCTOU attacks

There are many ways to address the threat of TOCTOU and simulation bypasses, but none of them are perfect on their own.

The Lighthouse Protocol injects an assertion instruction into transactions to ensure that the final state of a transaction matches what was expected during the simulation. 

If the transaction's conditions are altered after simulation, Lighthouse can detect the change and fail the transaction before it is executed.

However, this approach has its limitations. 

Adding instructions can cause transactions to exceed Solana’s size limits, making it impractical in some cases. 

More importantly, while Lighthouse helps mitigate simulation bypasses like TOCTOU attacks, it does not address the majority of wallet-draining attempts on Solana. 

To fully protect against a variety of threats, platforms and wallets need to adopt a multi-layered security strategy, including:

Program code analysis 

By analyzing the code of a program before the transaction is executed, security solutions can uncover hidden logic or potential vulnerabilities that could trigger malicious behavior later. 

For instance, Blockaid employs both static and dynamic code analysis that allows for a deeper understanding of how a program might behave once executed, uncovering patterns that may not be visible during simulation.

Address reputation checks 

Reviewing the history of addresses involved in a transaction can flag suspicious activity. If an address has been associated with malicious behavior, this can serve as an early warning sign, even if the simulation shows no issues.

dApp scanning 

Many wallet drainers share similar code patterns or infrastructure. Scanning dApps for these shared traits can help detect threats before they reach the transaction level, adding an additional layer of early protection.

By adopting these additional layers of defense, platforms can create a stronger, more comprehensive approach to security that addresses both TOCTOU attacks and the more frequent, direct wallet-draining schemes that don’t involve simulation bypasses.

Recap

A time-of-check-time-of-use (TOCTOU) attack is a type of exploit that takes advantage of the gap between when a system verifies something and when it acts on that verification.

Solana is particularly vulnerable because, when a user signs a transaction, they grant permission for all involved programs to modify writable accounts without restrictions.

This makes Solana highly dependent on accurate simulations to prevent potential drains of SOL or SPL tokens, which in turn makes TOCTOU attacks a serious threat to its users.

Mitigating TOCTOU attacks requires a broad approach that addresses the limitations of transaction simulations. 

While protocols like Lighthouse aim to reduce the risk of simulation bypasses, they alone are not enough to fully protect against evolving threats.

To safeguard users from TOCTOU attacks and other exploits, platforms need a comprehensive strategy. 

This means combining tools like Lighthouse with additional defenses, such as program code analysis, address reputation checks, and dApp scanning. 

Only by integrating these layers of protection can platforms provide the security necessary to keep their users safe from future attacks.

‍