How does a TOCTOU vulnerability work?

What a TOCTOU flaw really is

A TOCTOU flaw is a race between a check and the later use of the same object or state. The program first verifies something looks safe, then relies on that earlier result after an attacker or another process has changed the target in the meantime. The weakness is not the check itself, it is the non-atomic gap between verification and action.

This pattern shows up in file handling, permission checks, symlink resolution, object lookup and other code paths where state can be swapped quickly enough to make the earlier decision stale. The bug is often subtle because the validation step is correct in isolation, but the program assumes the world will stay unchanged until the use step completes.

In practice, TOCTOU becomes dangerous whenever the code makes a security decision based on a condition that can be altered after the decision but before the operation. That is why it belongs in secure coding reviews, especially around privileged code paths and any logic that decides access, ownership or trust based on filesystem or object state.

How the attack works in practice

An attacker looks for a window between validation and execution, then changes the object so the later use applies to something different from what was checked. A file may be replaced with a symlink, permissions may be changed, or a path may be redirected after the program has already accepted it as safe. The exploit succeeds when the program does not bind the check and the use to the same immutable state.

The attacker usually needs timing, but the exact method can vary. Fast repeated changes, concurrent access, symbolic links, hard links and other filesystem tricks can all help create the mismatch. The broader lesson is that any operation that treats a previously observed condition as still valid is vulnerable if an adversary can influence that condition before the action occurs.

Because the failure is temporal, simple validation logic is not enough. The right question is whether the code can perform the decision and the action as one atomic step, or whether it has to trust a state snapshot that may already be obsolete by the time it is used.

How to prevent stale-state checks from becoming a security bug

The best defense is to eliminate the gap, not merely to shorten it. Use atomic operations where possible, operate on file descriptors or handles instead of re-resolving names, and design privileged workflows so the object being acted on cannot be swapped after approval. For code that must inspect then act, the validation and the action should be coupled to the same object identity and the same access context.

Reviewing privileged code paths matters because TOCTOU bugs become much more damaging when the affected action runs with elevated rights. If a low-privilege user can influence what the privileged process will later open, execute, delete or modify, the bug can turn into privilege escalation or unintended access. Practical hardening also includes safe temporary-file handling, avoiding trust in mutable path lookups, and preferring APIs that reduce object substitution risk.

When complete elimination is not realistic, the fallback is to make the race useless. That means verifying the object again at the point of use, constraining what the process can touch, and ensuring any mismatch causes a safe failure rather than proceeding on stale assumptions. A secure design should assume that anything checked in one instant may be false in the next instant unless the code prevents change.

Risk and Threat Considerations

TOCTOU flaws matter because they let an attacker turn a legitimate security decision into a stale one. In privileged software, that can mean a file, object or permission set is checked as harmless and then swapped for something dangerous before the action executes.

Failure mechanism: The defender validates one state, but the program later acts on a different state because the target was changed in the gap between check and use. This is especially exploitable when the code re-resolves names, trusts mutable paths, or performs security-sensitive work after an asynchronous delay.

Impact: The result can be unauthorized file access, privilege escalation, object substitution, or corruption of security-sensitive operations. In a worst case, the attacker controls what a privileged process actually uses, not what it thought it had validated.

Practitioner Guidance

What to verify: Confirm whether the code validates a path, file or object and then re-opens or re-looks it up later. If it does, treat that as a candidate race unless the later action is bound to the same handle, descriptor or immutable reference.

Decision rule: If the action can affect privileged state, prefer atomic APIs or redesign the workflow so the check and use happen on the same object instance. If you cannot prove that binding, assume the control is bypassable under load or adversarial timing.

Practitioner takeaway: TOCTOU is fundamentally a trust problem about stale validation, so the secure pattern is to make the decision and the action inseparable wherever the result matters.

Related resources from NHI Mgmt Group

• Guide: CWE Top 25 Guide
• When should security teams escalate vulnerability work to leadership?
• When does risk-based prioritisation work better than simple vulnerability counting?
• Why do vulnerability backlogs keep growing even when teams work harder?
• How do SBOMs and vulnerability disclosures work together?