A time-of-check to time-of-use attack is a race condition where a system checks a resource, file, permission, or state, and that state changes before the system uses it. The attacker exploits the gap between verification and action, so a trusted check no longer matches the object actually accessed.
How TOCTOU attacks work
A TOCTOU flaw appears when a program verifies a resource or condition, then later acts on the assumption that nothing changed in between. That gap matters because the resource can be swapped, modified, or re-pointed after the check but before use, turning a trusted decision into an unsafe one.
The core weakness is not the check itself, but the separation between validation and action. Even strong validation can fail if the code reads a file, permission, path, object, or account state in one step and then relies on that earlier result in a later step without preserving the same target or state.
Why TOCTOU attacks are dangerous
TOCTOU bugs are dangerous because they can convert an apparently safe operation into one that affects the wrong object or proceeds under stale assumptions. In practice, that can lead to privilege abuse, unauthorized file access, incorrect security decisions, or execution against a different target than the one that was checked.
They are especially serious in concurrent, multi-user, and multi-process systems, where attackers can manipulate timing, scheduling, or filesystem state to widen the race window. The risk is often highest when the code assumes that a check establishes a lasting truth, rather than a momentary observation.
These weaknesses are commonly discussed alongside race conditions and related software weakness classes in Race Condition Vulnerabilities Guide and the broader CWE Top 25 Guide, because TOCTOU is often a symptom of unsafe sequencing, not a one-off coding mistake.
Common places TOCTOU flaws appear
TOCTOU issues show up wherever code checks state and later relies on it, especially with files, permissions, locks, symlinks, temporary paths, shared objects, or workflow decisions. The classic pattern is “check first, then use later,” with no guarantee that the object remains the same across both steps.
They also appear in security-sensitive operations such as access checks, ownership checks, and approval-style decisions, where the system validates one condition and then performs an action after the underlying state may already have changed. That is why a “pass” from the check phase does not automatically mean the use phase is safe.
In access workflows, the same design principle applies: if approval, expiry, or eligibility is evaluated separately from the actual access grant, the system can drift out of sync. For that reason, workflow design needs to preserve the decision context as tightly as possible, which is a concern also covered in the Access Request and Approval Workflow Design Guide.
How to reduce TOCTOU risk
The main defence is to remove the gap between verification and use. When that is not possible, the code should bind the decision to the same object or state it will later use, and it should fail safely if anything changes in between.
Practical hardening usually means atomic operations, safe locking, transactional updates, careful path handling, and designs that do not re-read a security-relevant object after a separate check. In file and filesystem contexts, that often means avoiding reliance on names alone and instead using primitives that keep the checked object fixed through the operation.
Where the system cannot fully eliminate the race window, compensating controls should reduce the attacker’s ability to exploit it, for example by narrowing privileges, isolating sensitive operations, and ensuring the code treats stale state as unsafe rather than authoritative.
Risk and Threat Considerations
TOCTOU attacks are attractive because they exploit a gap defenders often assume is harmless: the time between a security decision and the action that depends on it. That gap can let an attacker substitute a different object, alter state, or win a race that turns a legitimate check into an unsafe outcome.
Failure mechanism: The system validates one resource, path, or permission state, then uses a separate or later-observed state that the attacker changes before the action executes. That breaks the assumption that the checked object and the used object are the same.
Impact: The result can be unauthorized access, privilege misuse, incorrect file or object handling, or execution against the wrong target, often with effects that are difficult to spot after the fact.
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-6 — Access Control Management | TOCTOU often bypasses intended access decisions through timing gaps. |
| Recommendation — Use strict access-control enforcement and avoid split-phase permission checks for sensitive operations. | ||
| NIST SP 800-53 Rev 5 | SC-23 — Session Authenticity | TOCTOU can exploit stale trust in a checked state before use occurs. |
| AC-6 — Least Privilege | Limiting privileges reduces the blast radius when a race condition is won by an attacker. | |
| Recommendation — Preserve object and state authenticity from check through use and reject stale security decisions. Minimise privileges for race-sensitive code paths and sensitive file or object operations. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | TOCTOU is a secure design and implementation weakness around state validation and use. |
| Recommendation — Design security-sensitive actions to be atomic or state-bound so checks cannot be invalidated before use. | ||
| MITRE ATT&CK | T1610 — Deploy Container | Race conditions and TOCTOU-like flaws are often exploited during trusted-state transitions and runtime manipulation. |
| Recommendation — Map timing-sensitive exploit paths to attack-stage manipulation and tighten runtime trust boundaries. | ||
Practitioner Guidance
What to watch for: Treat any design that separates “verify” and “use” as a candidate race condition until proven otherwise. The strongest warning signs are repeated lookups, mutable shared state, filesystem indirection, and security checks that are not tied to the exact object later consumed.
Practitioner note: If the security decision matters, the safest design is usually the one that makes the check and the use part of the same atomic or state-preserving operation. When that is not feasible, assume the state can change and engineer the workflow so a change invalidates the action instead of silently permitting it.
Related resources from NHI Mgmt Group
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 November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org