What breaks when file access is checked and used in separate steps?

A Time of Check to Time of Use vulnerability appears when code validates a file or path, then acts on it after a gap. An attacker can change the underlying file between those steps, for example by swapping in a symlink or a different target. The result is that a trusted check applies to one object, while the actual operation hits another, potentially sensitive, file.

What the vulnerability actually breaks

Time of check to time of use breaks the assumption that a file you validated is still the same file when you act on it. The check and the use are separated by a window in which the target can change. That means the security decision is made against one object, while the later operation is applied to another, which can turn a safe-looking file access into an unsafe one.

This is not limited to obvious file replacement. Anything that changes the path resolution or backing object in the gap can invalidate the earlier decision, including symlink swaps, rename races, directory changes, and other reference changes that redirect the operation.

Why the gap creates a security failure

The core failure is that the code treats validation as if it were a guarantee of continuity. In reality, file state is mutable and the check does not lock the object unless the implementation explicitly uses atomic or descriptor-based handling. If the later operation follows a pathname again, the attacker can steer that second lookup to a different target and bypass the intent of the original check.

That is why TOCTOU is usually an integrity and privilege problem rather than just a programming bug. A process may believe it is opening, reading, writing, or executing a benign file, when it is actually touching a sensitive file that was substituted after validation.

How practitioners should think about fixing it

The right mental model is to remove the race, not to make the check “stronger.” A check that is repeated later, or a check that relies on path strings while the operation uses the path again, still leaves a gap. Safer designs keep the object stable across the operation, for example by using atomic operations, file descriptors, or APIs that combine verification and use in one step.

When you are reviewing code, look for any pattern that resolves a pathname, pauses, and then performs a separate access based on the same string. The more privileged the action, the more important it is to make the validation and the use inseparable. If the action can modify configuration, overwrite a protected file, or influence execution, treat the race as a real security boundary failure rather than a low-level timing issue.

Risk and Threat Considerations

TOCTOU becomes dangerous when the validated path controls a privileged action, because an attacker only needs to win the race once to redirect that action to a different file. The risk is highest where the process runs with elevated privileges or where the checked file name is attacker-influenced.

Failure mechanism: The application checks a pathname or file property, then reuses the path later instead of holding a stable reference, allowing the underlying object to change between those steps.

Impact: The attacker can swap in a symlink, replace the target, or otherwise redirect the operation so the code reads, writes, or executes a sensitive file it never intended to trust.

Standards & Framework Alignment

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

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	SI-2 — Flaw Remediation	TOCTOU is a code-level flaw that must be corrected in affected components.
	AC-3 — Access Enforcement	The bug bypasses intended access decisions by acting on a different object.
Recommendation — Patch or refactor affected code paths to remove the race condition. Enforce access decisions on the exact object that will be used.
OWASP ASVS	V15 — Secure Coding and Architecture	TOCTOU is a secure-design problem where validation and use must be atomic.
Recommendation — Design file-handling logic to bind validation and use into one safe operation.
CIS Controls v8	CIS-16 — Application Software Security	Application code must avoid race-prone file access patterns that create TOCTOU flaws.
Recommendation — Review and fix file-access logic to eliminate time-of-check/time-of-use races.

Practitioner Guidance

What to verify: Confirm whether the code performs the security decision on the same object that is later used, not just on the same string. If the access path is attacker-controlled or the operation is privileged, require an atomic design or a stable descriptor-based flow.

Common mistake: Rechecking the file after a delay is not a fix if the later operation still resolves the pathname again. That only narrows the window; it does not remove the race.

Practitioner takeaway: Treat TOCTOU as a trust-continuity problem, not a validation problem, and design the access path so the object cannot change between decision and action.