Join our Newsletter — 33% off our NHI Course

Time-of-Check to Time-of-Use (TOCTOU) Race Condition

Time-of-Check to Time-of-Use is a race condition where a checked value changes before the system acts on it. Attackers exploit the gap to bypass authorisation, swap files, or change data between validation and use. Defenders should make checks and use atomic, avoid shared mutable state, and minimise timing windows.

How TOCTOU race conditions work

A TOCTOU flaw appears when software checks a condition, then later relies on that same condition after the environment may have changed. The risk is not the check itself, but the assumption that the state remains stable between validation and action.

This is especially dangerous when the checked object is a file, path, permission state, lock, or other shared resource that can be changed by another thread, process, or attacker in the gap. Even a tiny window can be enough if the operation is repeated at scale or under contention.

Why TOCTOU is exploitable

Attackers look for any split between decision and enforcement, because the system often trusts the earlier result more than the later reality. That gap can let a malicious actor swap a file, redirect a path, alter metadata, or change a resource’s state after the check but before use.

The core weakness is shared mutable state combined with time delay. If the code performs a check on one version of an object and then acts on a different version, the intended control has already been bypassed even though each individual step may look correct in isolation.

Common failure patterns

TOCTOU shows up in file-system logic, privilege checks, temporary file handling, symbolic link handling, and any workflow that validates an object before a separate action consumes it. It also appears in distributed systems when state is read from one place and enforced somewhere else after delay.

  • Validation and execution are separated into different calls without locking or atomicity.
  • A pathname, file descriptor, or permission check is performed on one object, then the reference is reused later.
  • Temporary files or directories are created with predictable names or weak ownership assumptions.
  • Concurrency or retries create a wider timing window than the original design expected.

How defenders reduce TOCTOU exposure

Defensive design focuses on eliminating the gap, not merely making it smaller. The safest pattern is to combine verification and action in one atomic operation, or to hold a stable reference to the exact object being checked and used.

Practical mitigations include avoiding shared mutable state where possible, using race-safe APIs, relying on file descriptors or equivalent immutable handles, and treating timing-sensitive code paths as security-critical. For coding practices that help prevent this class of weakness, see the Secure Coding Guide and the CWE Top 25 Guide.

Risk and Threat Considerations

TOCTOU is dangerous because it can turn an apparently valid security decision into a bypass, especially when the target is a permissioned file, privileged action, or security-sensitive data path. The issue becomes more serious under load, in concurrent systems, or when an attacker can repeatedly trigger the sequence until the timing aligns.

Failure mechanism: The attacker changes the object, path, or state after the program checks it but before the program uses it, so the later action operates on a different reality than the earlier decision.

Impact: That mismatch can enable authorisation bypass, file substitution, tampering, privilege abuse, or unsafe execution of a resource that was never meant to pass the original check.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
CIS Controls v8 CIS-3 — Data Protection TOCTOU can expose or alter sensitive data between validation and use.
Recommendation — Protect sensitive objects with race-safe access paths and atomic state transitions.
NIST SP 800-53 Rev 5 SC-39 — Process Isolation TOCTOU exploits shared-state gaps between check and use across processes.
AC-6 — Least Privilege TOCTOU often turns a narrow timing gap into unauthorized access or misuse.
Recommendation — Isolate security-sensitive processes to reduce race opportunities between validation and action. Limit the privileges available during race-prone operations so a successful swap has less impact.
OWASP ASVS V15 — Secure Coding and Architecture TOCTOU is a software design weakness that secure architecture and coding practices should prevent.
Recommendation — Design checks and use paths so security decisions are enforced atomically.
MITRE ATT&CK T1205 — Traffic Signaling Race-condition exploitation often depends on precise timing and repeated triggering.
Recommendation — Hunt for repeated trigger patterns that align attacker actions with security-sensitive timing windows.

Practitioner Guidance

What to watch for: Any security control that depends on reading state first and acting later should be reviewed for atomicity, because that pattern is where TOCTOU weaknesses usually appear. The risk is often hidden in apparently ordinary code, such as validation helpers, temporary-file workflows, or permission checks split across multiple functions.

Practitioner note: When reviewing code, focus less on whether the check is correct and more on whether the checked object can still change before the action occurs. If it can, the design still has a race, even if the logic looks sound on paper.