What Is a TOCTOU Race Condition and How Do You Prevent It?

A TOCTOU race condition is a flaw where software checks the state of a resource, then uses it later, and the state changes in between. The check result is stale by the time the program acts on it. TOCTOU stands for time of check to time of use, and MITRE tracks it as CWE-367. Preventing it means closing that gap or making the check and the use a single step.

What is a TOCTOU race condition?

It is a bug in the order of operations: a program validates something and then relies on that validation after another actor has had a chance to change the result. MITRE's definition says the state "can change between the check and the use in a way that invalidates the results of the check."

The check itself can be perfectly correct. The problem is the assumption that the answer stays true. Any resource that another process, user or request can touch is exposed to this assumption, which is why files, directories and shared records are common places to find it.

Why is it called a race condition?

Two activities run at the same time, and the outcome depends on which one reaches the resource first. The attacker is racing the program, trying to act inside the gap between its check and its use.

That makes these flaws probabilistic. A single attempt usually misses. Repeated attempts improve the odds, so defenders often see them as sustained, repetitive traffic or activity instead of one distinctive request.

A classic TOCTOU example

The CWE-367 entry gives a standard example in C. A program calls access() to confirm the user may write to a file, then calls fopen() to open it. Both calls work on a filename, not on a file handle, so nothing guarantees the name points to the same file at both moments.

A second example in the same entry uses PHP. Code calls is_link() to reject symbolic links, then calls file_get_contents() to read the file. An attacker who swaps a real file for a symbolic link between those two calls can read a file the check was meant to protect.

Neither example has a broken check. Each fails because time passes between the check and the action.

A real-world case: the WordPress upgrade window

WordPress CVE-2026-119977 shows the same weakness at a larger scale, and its CVE record maps it to CWE-367. During a full-package core update, affected versions unpacked a complete copy of WordPress into a predictable folder under wp-content/upgrade/. On many servers that folder is reachable from the web.

The live site was protected by its configuration, but the temporary copy was briefly a separate, unconfigured install. Its installer could run without the live site's settings. WordPress assumed nobody would reach the folder during the few seconds it existed, and that assumption was the weak point.

The fix follows the prevention patterns below. WordPress 7.1.4 adds 16 random characters to the folder name, so it cannot be guessed, and keeps an index.php in place, so it cannot be listed. Our guide on how to block web access to wp-content/upgrade adds a second layer at the web server.

How serious is a TOCTOU flaw?

The impact depends on what the check protected, and it can range from reading one file to running code on the server. Timing makes these flaws harder to exploit, but it does not reduce the damage once the race is won.

CVSS captures this split. The specification gives "repeated exploitation to win a race condition" as an example of high attack complexity, which lowers the score without changing the impact ratings. That is one reason vendor severity and CVSS scores can disagree on the same bug.

How do you prevent TOCTOU race conditions?

Remove the gap where you can, and reduce what an attacker can do inside it where you cannot. CWE-367 recommends limiting the interleaving of operations on files from multiple processes and rechecking the resource after the use call.

These practices apply in most code reviews:

• Work on handles, not names. MITRE's C example fails because both calls take a filename. Open the resource once, then run checks on what you actually opened.
• Recheck after use. Confirm the action did what you intended, and fail closed if it did not.
• Keep temporary work out of reachable locations. A staging directory outside the web root cannot be requested over HTTP, however long it exists.
• Make names unpredictable. Random names raise the cost of finding a temporary path, as the WordPress fix does. Treat this as added protection, because a name that leaks or can be listed loses that benefit.
• Limit who can touch the resource. If only one service account can write to a directory, far fewer actors can change state during the gap.

Where to look for TOCTOU in your own systems

Search for places where a privileged process acts on something another party can influence:

• Update and installer routines that unpack files before moving them into place
• Upload handlers that validate a file, then process it from a shared path
• Scripts running as root that work in world-writable directories such as temporary folders
• Permission checks followed by a separate action on the same object

Vendor software is harder to inspect, so focus on what you control. Check which temporary and update directories your web server will serve, and block any that do not need public access. When your logs show repeated requests for a path that rarely exists, read that as a possible race attempt and compare the timing against your maintenance windows.