Time-Of-Check Time-Of-Use (TOCTOU) Exploit

How a TOCTOU exploit works

A time-of-check time-of-use flaw is a classic concurrency problem: the system validates one state, then later acts on that same assumption after the state may already have changed. The gap can exist around files, permissions, paths, objects, or request data, and the exploit succeeds when an attacker can alter the target in between those two steps.

The issue is not the check itself, but the broken assumption that the checked condition will still be true at use time. In practice, TOCTOU often appears where security decisions are split across multiple system calls, processes, threads, or trust boundaries. The more mutable the object and the wider the window, the easier it is to abuse.

TOCTOU is closely related to race conditions, but the security impact is specific: a later action applies to something different from what was verified. That can turn a seemingly safe validation into an unsafe write, execution, permission change, or file operation. For a deeper treatment of how these flaws arise and how to design them out, see the Race Condition Vulnerabilities Guide.

Common exploitation paths

Attackers usually look for any sequence where verification and action are separated by delay, context switching, or re-resolution of a resource. Typical examples include symbolic link swaps, temporary file replacement, permission flips, path changes, or object substitution after an access check has passed. The exploit often depends on timing, but the underlying weakness is the non-atomic design.

File handling is a frequent target because many programs check a pathname, ownership, or access mode and then open or modify the resource later. If the name can be redirected or the object swapped, the program may end up reading the wrong file, writing to a protected one, or executing content that was never intended to be trusted. Similar patterns occur in request processing when a decision is made on one object version and consumed on another.

TOCTOU also matters beyond low-level filesystems. Any workflow that verifies eligibility, authorization, state, or integrity and then acts later can be vulnerable if the state is not pinned or the transaction is not atomic. That is why secure designs prefer operations that combine validation and use into one indivisible step.

Why it is dangerous

The security danger is that the verifier and the consumer are no longer talking about the same thing. A system can appear to have strong validation while still being exploitable because the verified state is only momentarily true. This makes TOCTOU flaws especially hard to spot in code review, since each individual step may look reasonable in isolation.

Once exploited, the impact can range from unauthorized file access to privilege abuse, data corruption, code execution, or denial of service. In business workflows, the same weakness can undermine approvals, approvals-by-reference, and other controls that rely on a stable object identity between decision and execution.

Because the flaw is about state drift, the attacker does not need to defeat the check directly. They only need to change the target before the use step consumes it. That makes TOCTOU a trust-boundary problem as much as a timing problem, and it is one reason atomic design and object binding are so important in secure systems.

Detection, prevention, and safer design

Prevention starts with eliminating the gap wherever possible. The strongest pattern is to use atomic operations, lock the relevant object or namespace, and avoid re-checking a mutable reference after the decision has been made. When the design cannot be fully atomic, the system should validate the exact object it will later use, not a proxy for it.

Development teams should also look for symbolic-link handling, temporary file creation, rename races, re-validated permissions, and any code that checks state in one function and uses it in another without a protected handoff. Review should focus on whether the security property is preserved at the moment of use, not only at the moment of inspection. For a broader software-weakness lens on this class, the CWE Top 25 Guide is a useful reference point.

At the operational level, testing should include race-focused abuse cases, especially around file creation, permission checks, and request workflows. If the system already exposes the relevant weakness class to defenders, the Vulnerability Management Guide helps teams think about finding, prioritising, and verifying exposure to exploitable weaknesses. Where exploitation is active or timing windows are being weaponised, the Zero-Day and Exploited Vulnerabilities Guide is a useful companion for triage and post-exploitation review.

Practitioner Guidance

What to watch for: Treat any security control that depends on a mutable object, path, or state snapshot as suspect unless the check and use are bound together. If the code or workflow can be made to act on a different object than the one it validated, the design is still vulnerable even when the individual checks are correct.

Governance implication: Ownership should sit with the team that controls the transaction boundary, because TOCTOU is usually fixed in architecture and implementation, not by a policy add-on. The practical goal is to make the security decision and the action inseparable wherever the system stores, opens, authorises, or modifies a sensitive resource.

Practitioner takeaway: When you cannot make the action atomic, assume the state can change and redesign the control so the system binds the decision to the exact object it will use.

Related resources from NHI Mgmt Group

• Time-of-check/time-of-use (TOCTOU)
• Time of Check
• 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)?