Software Engineering · Security

TOCTOU Race Condition

Reference entry · last updated August 24, 2026

Time-of-check to time-of-use (TOCTOU), also written TOCTTOU, is a class of software bug in which a program checks the state of a resource and then acts on that state, but the resource is able to change in the interval between the check and the use — so the check's result is stale by the time the program relies on it.[1] It is a specific kind of race condition: the "race" is between the checking step and whatever else, running concurrently, can alter the resource before the using step executes.

The general shape

Every TOCTOU bug follows the same two-step pattern:

Check — the program queries a resource's current state (a file's permissions, a slot's availability, a balance, a lock's status).
Use — the program acts as if that state still holds (opens the file, confirms the booking, debits the balance, enters the critical section).

The bug lives in the gap between the two steps. If nothing else in the system can touch that resource during the gap, the check remains valid and there is no bug. A TOCTOU vulnerability exists specifically when something else — another process, another thread, another user, an attacker — can act on the same resource during that window, making the check's answer wrong by the time the use step trusts it.

Classic example

The canonical case is a Unix program that calls access() to check whether the calling user has permission to open a file, then calls open() on the same path shortly after. Between the two calls, an attacker with write access to the containing directory can delete the original file and replace the path with a symbolic link to a different, sensitive file. The access() check ran against the original file; the open() call follows the now-substituted symlink, and the program acts on a file it never actually checked.[1] This exact pattern accounts for a long-running category of Unix security advisories, since the check and the use are two separate system calls with an attacker-controllable filesystem in between.

Why it is called a race condition

A race condition, generally, is any situation where a system's correctness depends on the relative timing of events that are not otherwise synchronized. TOCTOU is a race between the checking actor and whatever else can modify the resource: if the other actor's modification lands inside the gap, the program loses the race and acts on stale information. If it lands outside the gap — before the check or after the use completes — there is no observable bug, which is what makes TOCTOU issues intermittent and hard to reproduce on demand.

What is not a TOCTOU

Two properties have to both be present for a real TOCTOU race: a genuine elapsed-time gap between check and use, and a second actor (or process, or thread) capable of changing the resource's state during that gap. A function that reads a value from static, precomputed configuration and returns it — with no other process able to alter that configuration between the read and whatever consumes it — is not exhibiting a TOCTOU race, even if a narrative description of the same code uses check-then-act language ("it looked available, then it wasn't"). Without a concurrent second actor and a real window of elapsed time in which state could actually change, the situation is a deterministic lookup, not a race: the same input will produce the same "checked" result every time, which a genuine race condition, by definition, will not.

Mitigations

The standard fix is to collapse the two separate steps into one atomic operation, so no window exists for another actor to intervene:

Atomic operations — using a single system call or API that performs the check and the use together (for example, opening a file with flags that fail if it already exists, rather than checking existence and then creating it as two calls).
Locking — holding an exclusive lock on the resource from before the check until after the use completes, so no other actor can modify it in between.
Optimistic concurrency / versioning — reading a version number or timestamp alongside the state, then making the update conditional on that version being unchanged at write time; the update itself detects and rejects a stale check instead of trusting it blindly.

References

^ "CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition," Common Weakness Enumeration, MITRE Corporation — https://cwe.mitre.org/data/definitions/367.html

A freely-accessible copy of Bishop & Dilger's foundational 1996 paper on checking for TOCTOU races in file accesses (Computing Systems 9(2)) was not located at time of writing; not cited here to avoid pointing to a dead or paywalled link.