logo

Time-of-check Time-of-use (TOCTOU) Race Condition

Incomplete Base
Structure: Simple
Description

This vulnerability occurs when a program verifies a resource's state (like a file's permissions or existence) but then uses it after that state has already changed. The gap between checking and using creates a race window where an attacker can manipulate the resource, causing the program to operate on invalid or malicious data.

This vulnerability occurs when a program verifies a resource's state (like a file's permissions or existence) but then uses it after that state has already changed. The gap between checking and using creates a race window where an attacker can manipulate the resource, causing the program to operate on invalid or malicious data.
Extended Description

Think of this as a classic bait-and-switch attack against your code. Your application acts on a decision that was correct a moment ago but is now dangerously wrong. For example, your code might check that a file is owned by a safe user, but an attacker quickly swaps it with a symbolic link to a sensitive system file before your code opens it. This time-of-check to time-of-use (TOCTOU) gap is especially common in file system operations, but can also affect shared memory, process states, or even security tokens. To defend against this, you must design your operations to be atomic—meaning the check and the use must happen as a single, uninterruptible action. Use file handles or descriptors instead of pathnames after validation, leverage file-locking mechanisms carefully, or employ secure APIs that internally manage state consistency. Always assume the environment can change between any two consecutive operations, and structure your code to minimize or eliminate these risky time windows.
Common Consequences 6
Scope: IntegrityOther

Impact: Alter Execution LogicUnexpected State

The attacker can gain access to otherwise unauthorized resources.

Scope: IntegrityOther

Impact: Modify Application DataModify Files or DirectoriesModify MemoryOther

Race conditions such as this kind may be employed to gain read or write access to resources which are not normally readable or writable by the user in question.

Scope: IntegrityOther

Impact: Other

The resource in question, or other resources (through the corrupted one), may be changed in undesirable ways by a malicious user.

Scope: Non-Repudiation

Impact: Hide Activities

If a file or other resource is written in this method, as opposed to in a valid way, logging of the activity may not occur.

Scope: Non-RepudiationOther

Impact: Other

In some cases it may be possible to delete files a malicious user might not otherwise have access to, such as log files.

Scope: Other

Impact: Unexpected State

The product may perform invalid actions when the resource is in an unexpected state.
Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 7
Phase: Implementation
The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.
Phase: Implementation
When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.
Phase: Architecture and Design
Limit the interleaving of operations on files from multiple processes.
Phase: ImplementationArchitecture and Design
If you cannot perform operations atomically and you must share access to the resource between multiple processes or threads, then try to limit the amount of time (CPU cycles) between the check and use of the resource. This will not fix the problem, but it could make it more difficult for an attack to succeed.
Phase: Implementation
Recheck the resource after the use call to verify that the action was taken appropriately.
Phase: Architecture and Design
Ensure that some environmental locking mechanism can be used to protect resources effectively.
Phase: Implementation
Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use.
Demonstrative Examples 4
The following code checks a file, then updates its contents.

Code Example:

Bad
C
c
Potentially the file could have been updated between the time of the check and the lstat, especially since the printf has latency.
The following code is from a program installed setuid root. The program performs certain file operations on behalf of non-privileged users, and uses access checks to ensure that it does not use its root privileges to perform operations that should otherwise be unavailable the current user. The program uses the access() system call to check if the person running the program has permission to access the specified file before it opens the file and performs the necessary operations.

Code Example:

Bad
C
c
The call to access() behaves as expected, and returns 0 if the user running the program has the necessary permissions to write to the file, and -1 otherwise. However, because both access() and fopen() operate on filenames rather than on file handles, there is no guarantee that the file variable still refers to the same file on disk when it is passed to fopen() that it did when it was passed to access(). If an attacker replaces file after the call to access() with a symbolic link to a different file, the program will use its root privileges to operate on the file even if it is a file that the attacker would otherwise be unable to modify. By tricking the program into performing an operation that would otherwise be impermissible, the attacker has gained elevated privileges. This type of vulnerability is not limited to programs with root privileges. If the application is capable of performing any operation that the attacker would not otherwise be allowed perform, then it is a possible target.

ID : DX-49

This code prints the contents of a file if a user has permission.

Code Example:

Bad
PHP
php

//resolve file if its a symbolic link* if(is_link($filename)){ ``` $filename = readlink($filename); } if(fileowner($filename) == $user){ echo file_get_contents($realFile); return; } else{ echo 'Access denied'; return false; } }

This code attempts to resolve symbolic links before checking the file and printing its contents. However, an attacker may be able to change the file from a real file to a symbolic link between the calls to is_link() and file_get_contents(), allowing the reading of arbitrary files. Note that this code fails to log the attempted access (Insufficient Logging).
This example is adapted from [REF-18]. Assume that this code block is invoked from multiple threads. The switch statement will execute different code depending on the time when MYFILE.txt was last changed.
Code Example:
Bad
C
c
If this code block were executed within multiple threads, and MYFILE.txt changed between the operation of one thread and another, then the switch could produce different, possibly unexpected results.
  
Observed Examples 5
CVE-2015-1743TOCTOU in sandbox process allows installation of untrusted browser add-ons by replacing a file after it has been verified, but before it is executed
CVE-2003-0813Chain: A multi-threaded race condition (Time-of-check Time-of-use (TOCTOU) Race Condition) allows attackers to cause two threads to process the same RPC request, which causes a use-after-free (Use After Free) in one thread
CVE-2004-0594PHP flaw allows remote attackers to execute arbitrary code by aborting execution before the initialization of key data structures is complete.
CVE-2008-2958chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
CVE-2008-1570chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
  
References 4
The CLASP Application Security Process
Secure Software, Inc.
2005
https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf(2024-11-17)
ID: REF-18
Portably Solving File TOCTTOU Races with Hardness Amplification
Dan Tsafrir, Tomer Hertz, David Wagner, and Dilma Da Silva
28-02-2008
https://www.usenix.org/legacy/events/fast08/tech/tsafrir.html(2023-04-07)
ID: REF-367
24 Deadly Sins of Software Security
Michael Howard, David LeBlanc, and John Viega
McGraw-Hill
2010
ID: REF-44
The Art of Software Security Assessment
Mark Dowd, John McDonald, and Justin Schuh
Addison Wesley
2006
ID: REF-62
 
  
  
 
 
Likelihood of Exploit 
 
 
 
 Medium 
 
 
  
 
 
Applicable Platforms 
 
 
 
 
 
Languages:
 
 
 Not Language-Specific : Undetermined 
  
  
 
 
 
  
 
 
Modes of Introduction 
 
 
 
 
 
  Implementation  
 
 
 
  
Related Attack Patterns 
  
Alternate Terms 
TOCTTOU
The TOCTTOU acronym expands to "Time Of Check To Time Of Use".
TOCCTOU
The TOCCTOU acronym is most likely a typo of TOCTTOU, but it has been used in some influential documents, so the typo is repeated fairly frequently.
    
 
 
Affected Resources 
 
 
 
     
  1. File or Directory
    2.  
 
 
  
 
 
Related Weaknesses 
 
 
 
 
  ChildOf:
 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') (CWE-362) 
  ChildOf:
 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') (CWE-362) 
 
 
 
 
Taxonomy Mapping 
  • PLOVER
  • 7 Pernicious Kingdoms
  • CLASP
  • CLASP
  • CERT C Secure Coding
  • Software Fault Patterns
  
Notes 
RelationshipTOCTOU issues do not always involve symlinks, and not every symlink issue is a TOCTOU problem.
Research GapNon-symlink TOCTOU issues are not reported frequently, but they are likely to occur in code that attempts to be secure.