CWE-367 is a race condition called time-of-check to time-of-use, where a program checks a resource and then uses it later after the state may have changed. It matters in access control, file handling and privilege checks, because an attacker can change the target between the check and the use.
What TOCTOU Means in Practice
Time-of-check to time-of-use, or TOCTOU, is a race condition where a program verifies a resource or condition, then later acts on that earlier result after the state may have changed. The weakness is the gap between decision and execution.
That gap matters whenever security depends on the resource staying unchanged, especially for files, permissions, ownership, locks, and privileged operations. If an attacker can alter the target during the window, the program may end up using a different object than the one it examined.
TOCTOU is usually discussed as a logic flaw rather than a memory-safety bug. The core problem is not that the check is wrong, but that the check is no longer valid by the time the use happens.
Why TOCTOU Is Dangerous
The risk comes from false confidence. A program may check that a file is safe, that a path belongs to the expected user, or that a privilege condition is satisfied, then proceed as if that fact is still true. In concurrent systems, that assumption can fail between two instructions.
Attackers often look for TOCTOU in code that crosses trust boundaries, such as temporary files, symlink handling, file replacement, and permission-dependent operations. The weakness can turn a harmless read into an unsafe write, or a denied action into a permitted one.
Because the flaw depends on timing, it can be intermittent and hard to reproduce. That makes it especially dangerous in production, where load, scheduling, and filesystem behaviour can widen the exploitable window.
Where TOCTOU Appears
TOCTOU is most visible in file handling, access control, and privilege checks, but the pattern is broader than files alone. Any workflow that checks a condition first and relies on it later can be vulnerable if the underlying state is mutable.
- File existence, type, ownership, or permissions checks before opening or writing a file.
- Path validation before a later filesystem operation that follows links or replaces the target.
- Privilege checks before executing an action that depends on the same subject, object, or token remaining unchanged.
- Workflow decisions that assume a resource, session, or object state has not changed since validation.
The common failure pattern is separation: validation happens in one moment, use happens in another, and no atomic guarantee binds them together.
How to Prevent and Detect TOCTOU
The strongest defense is to make the check and the use atomic, or as close to atomic as the platform allows. Where that is not possible, designs should reduce reliance on mutable assumptions and use secure primitives that preserve object identity across the operation.
Practical hardening often includes opening the object first and validating the already-open handle, using atomic filesystem operations, constraining permissions, and avoiding patterns that re-resolve a path after validation. Defensive reviews should look for any code that validates one reference but later acts on another.
Detection is harder than prevention, but suspicious patterns include repeated retries, unexpected object replacement, and security decisions that fail only under concurrency. Review code paths that combine validation, user-controlled input, and a delayed privileged action. For broader software weakness context, see the CWE Top 25 Guide and the CVE, CWE and CPE Guide.
For concurrency-focused design patterns, atomicity, locking, isolation, and idempotent operations are the main ideas that remove the exploitable gap. NHIMG’s Race Condition Vulnerabilities Guide explains how those controls help design TOCTOU flaws out of a system.
Risk and Threat Considerations
TOCTOU becomes dangerous when an attacker can influence the resource between validation and use, especially in privileged or security-sensitive code paths. The result can be authorization bypass, unsafe file access, or execution against a different object than the one that was checked.
Failure mechanism: The program makes a decision based on an earlier state snapshot, then reuses that decision after the resource has been replaced, relinked, or otherwise changed.
Impact: An attacker can redirect the operation, escalate privileges, overwrite protected data, or cause the system to trust an object that no longer matches the original check.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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-5 — Account Management | TOCTOU often exploits stale permission and ownership decisions. |
| Recommendation — Enforce account and access review controls that prevent stale privilege decisions from being reused after state changes. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | TOCTOU breaks enforcement when authorization is checked before use. |
| AC-6 — Least Privilege | Limiting privilege reduces the impact when a TOCTOU flaw is exploited. | |
| Recommendation — Bind access decisions to the live object or operation at execution time. Constrain the operating context so a race cannot reach more privilege than necessary. | ||
| OWASP ASVS | V8 — Authorization | TOCTOU is a classic authorization timing failure in application logic. |
| V15 — Secure Coding and Architecture | The weakness reflects unsafe separation of validation and use in code design. | |
| Recommendation — Verify authorization at the point of action and avoid relying on earlier checks. Design operations so validation and use are atomic or otherwise safely bound. | ||
Practitioner Guidance
What to watch for: Audit code where a security decision and the resulting operation are separated by time, especially when paths, file descriptors, permissions, or ownership are involved. The most reliable fixes are architectural, not cosmetic, because shortening the window is weaker than removing the window entirely.
Practitioner note: If you can state the security decision in one sentence but cannot show how the same object remains bound to the later use, you probably have a TOCTOU review problem.
Related resources from NHI Mgmt Group
- What do teams get wrong when they rely on top CWE rankings alone?
- Why do repeat CWE classes keep causing breaches even when teams know about them?
- How should security teams use the CWE Top 25 and OWASP Top 10 together without duplicating work?
- Why do CWE-level findings provide stronger audit evidence than OWASP category labels?
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