TOCTOU is a race condition where a system checks a condition and then uses the result later, after the state may have changed. In security, an attacker can swap a file, link, or permission between the check and the use, so access decisions or file operations rely on stale information.
How TOCTOU Works
TOCTOU is a classic race condition: a program checks a fact, then later acts on it after the underlying state may have changed. The gap between verification and use is the vulnerability, because the earlier check no longer guarantees the later operation is safe.
This pattern appears in file handling, permission checks, path resolution, and many other operations where state can be swapped, updated, or redirected between two separate steps. The flaw is not the check itself, but the assumption that the checked state remains stable long enough for the use.
Why TOCTOU Becomes a Security Problem
In security-sensitive code, TOCTOU can let an attacker replace a file, change a symlink target, alter ownership or permissions, or otherwise influence what the system actually touches after the check. That can turn an apparently safe decision into unauthorized access, data tampering, or execution of the wrong object.
The danger is greatest when the check and use are separated by process scheduling, I/O delays, or multiple system calls. The longer the gap, the more opportunities exist for another actor, thread, or process to change the state that the decision depended on.
It is also why seemingly minor design choices matter. A security check that is logically correct can still fail if it is not coupled tightly enough to the operation it is supposed to protect.
Common Places TOCTOU Appears
TOCTOU often shows up in file-system paths, temporary files, symbolic links, hard links, access-control decisions, and privileged maintenance tasks. Any workflow that first validates a resource and then reopens or reuses it later can be vulnerable if the resource identity is not fixed.
It can also appear outside file operations. Authorization decisions, feature flags, inventory checks, quota checks, and object lookups may all be vulnerable when the system relies on a stale snapshot rather than a single authoritative operation.
- File existence checks followed by later open or write operations.
- Permission or ownership checks followed by delayed access.
- Temporary-file workflows that assume the pathname still refers to the same object.
- Multi-step authorization logic that does not bind the decision to the exact object or action.
How Teams Reduce TOCTOU Exposure
Good defensive design tries to collapse the check and the use into one atomic action, or to bind them so tightly that the checked object cannot be swapped out in the middle. That may involve atomic file operations, safer system calls, stronger locking, immutable handles, or designs that avoid trust in mutable paths altogether.
Where atomicity is not possible, developers should reduce the time window, remove trust in intermediate state, and prefer APIs that operate on an already-open handle or a stable identifier. The practical goal is to make the decision and the action refer to the same object, not merely the same name.
For sensitive workflows, review should focus on any place where state is validated in one step and assumed unchanged in a later step. That review is often more useful than looking only for obvious permission bugs, because TOCTOU is fundamentally about timing and state drift.
Risk and Threat Considerations
TOCTOU matters because an attacker does not need to break the initial check, only to change the target before the later use. That makes the weakness especially dangerous in privileged file operations, security-sensitive automation, and any workflow that trusts mutable system state.
Failure mechanism: The system validates one object or condition, then uses a separate later reference after an attacker, thread, or process has changed the underlying state, so the action applies to something different from the thing that was checked.
Impact: This can produce unauthorized reads or writes, privilege abuse, incorrect execution, and in some cases code execution or persistent system compromise when the swapped object is security-critical.
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 NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-39 — Process Isolation | TOCTOU exploits state changes between check and use, which process isolation helps contain. |
| AC-6 — Least Privilege | TOCTOU becomes more damaging when a raced operation runs with elevated rights. | |
| Recommendation — Isolate sensitive operations so one process cannot alter the state another process just validated. Limit privileges on file and permission workflows so a raced action cannot perform broad damage. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | ASVS covers secure design choices that prevent race conditions and unsafe state assumptions. |
| Recommendation — Design sensitive operations to avoid split validation and use paths that create race windows. | ||
| MITRE ATT&CK | T1036 — Masquerading | TOCTOU can be used to swap the object or path a defender believes it validated. |
| Recommendation — Map suspicious path and object-swapping behavior to deception techniques during detection. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Secure configuration reduces unsafe file, path, and permission defaults that amplify TOCTOU risk. |
| Recommendation — Harden file and permission settings so mutable objects are harder to abuse between check and use. | ||
Practitioner Guidance
What to watch for: Any code path that performs a check and then re-resolves the same resource later deserves scrutiny, especially when the object can move, be replaced, or be observed through a pathname rather than a stable handle. Separate validation and action steps are often a warning sign in privileged code.
Governance implication: Security review should treat atomicity as a design requirement for sensitive operations, not an optimisation. If a workflow cannot keep the checked state stable through the use, the control design should change rather than relying on procedural caution.
Related resources from NHI Mgmt Group
- Guide: Race Condition Vulnerabilities Guide
- Is CVE-2025-38352 (Linux Kernel Time-of-Check Time-of-Use (TOCTOU) Race Condition) being exploited in the wild?
- How do you patch or mitigate CVE-2025-38352 (Linux Kernel Time-of-Check Time-of-Use (TOCTOU) Race Condition)?
- What causes Time-of-check Time-of-use (TOCTOU) Race Condition?
- Time-of-check/time-of-use (TOCTOU)
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org