TOCTOU attacks bypass scanners by design, not by chance

At a glance

What this is: This article explains why TOCTOU attacks defeat snapshot-based checks and why runtime enforcement at the syscall is the effective control.

Why it matters: It matters because identity, workload, and container controls that validate once and trust afterward can be bypassed when the resource changes between check and use.

Context

TOCTOU, or time-of-check to time-of-use, is a race condition where a system validates a resource and then acts on it later. In security terms, that gap matters because the object seen by the checker is not guaranteed to be the object used by the operation, which makes snapshot controls fragile in dynamic environments.

The article’s core governance problem is not weak validation but misplaced trust in pre-execution checks. In Kubernetes, CI workspaces, shared volumes, and other mutable paths, the identity of the resource can change after approval, so the control point has to move to the moment of use. That is why the topic intersects with workload identity and runtime policy, not just application security.

Key questions

Q: What breaks when a security check and the real file use happen at different times?

A: The check can still be correct and the control can still fail. If an attacker changes the object between validation and use, the operation runs against something different from what was approved. That is why TOCTOU is a race condition, and why enforcement has to happen at the point of use rather than at a preflight step. See the 52 NHI breaches Report for related governance patterns around runtime trust.

Q: Why do scanners fail against TOCTOU attacks in mutable environments?

A: Scanners see a snapshot, not the live runtime object. If the workload can change a path, mount point, or file between scan and use, the scanner’s verdict no longer describes the object the kernel will act on. Prevention requires time-of-use enforcement, not only earlier inspection.

Q: What are the signs that runtime controls are too early to stop TOCTOU?

A: The main signs are path-based checks, userspace guards, admission approvals, and file validations that happen before the kernel resolves the object. If the control can be bypassed by a symlink swap, rename, or writable volume change, it is protecting the wrong moment in the workflow.

Q: When should teams rely on syscall-level enforcement instead of preflight checks?

A: Use syscall-level enforcement whenever the protected object can change after review, especially in containers, CI workspaces, and setuid code paths. Preflight checks still help with posture, but they cannot stop a race once the resource is mutable. Runtime policy is the control that makes the check and the use converge.

Technical breakdown

Why TOCTOU becomes a race condition

TOCTOU attacks work because the check and the use are separate events. A program may confirm that a file, path, or object is safe at one moment, but another process can change that object before the privileged operation executes. The result is stale validation. Classic examples include access() followed by open(), where the path argument is reused but the underlying object is swapped through a symlink or rename. The weakness is structural, not incidental: any control that evaluates a snapshot and then trusts it later can be beaten if the attacker controls the interval.

Practical implication: Treat any pre-use approval as advisory unless the enforcement point runs on the resolved object at the moment of action.

Why scanners and admission checks miss the attack

Scanners and admission controllers are time-of-check mechanisms. They can tell you what existed in an image, manifest, or filesystem when they inspected it, but they do not guarantee that the same object still exists when the workload runs. That distinction matters in containerized and CI environments, where writable volumes, symlink swaps, and rapid file changes are normal. The control failure is not that the scan was incorrect. It is that the attack happens after the scan has already finished, so the security decision no longer describes the live runtime state.

Practical implication: Use scanners to find posture issues, but do not rely on them to prevent runtime resource swapping attacks.

How syscall-level enforcement closes the window

Linux Security Module hooks and eBPF enforcement change the control point from inspection to execution. When policy fires at file_open, bprm_check_security, or related kernel hooks, the kernel has already resolved the real object, so the check and the use converge on the same event. That removes the swap window that TOCTOU needs. This is why runtime enforcement is materially different from a userspace guard: the attacker cannot race a kernel decision that happens at the exact moment the operation commits. In identity terms, the policy is bound to the live workload action, not to an earlier claim about what the action will be.

Practical implication: Place policy at syscall time for sensitive file, process, and library operations where object mutation is possible.

Threat narrative

Attacker objective: Force a trusted process to operate on a different object than the one it checked, so privileged actions land on attacker-chosen targets.

1. Entry occurs when an attacker can influence a mutable path or resource that a privileged program will later use.
2. Credential access is not the core issue here, because the abuse path is resource substitution rather than stolen authentication material.
3. Escalation happens when the program reuses a previously validated path and performs a privileged action on the attacker-controlled object.
4. Impact is overwrite, code execution, or filesystem compromise through a check that passed against one object and was used against another.

NHI Mgmt Group analysis

TOCTOU is a control-placement problem, not a scanner-quality problem. The article shows that once validation and execution are separated, an attacker only needs to win the interval. That means the real question is where the policy decision occurs, not how thorough the earlier inspection looked. For workload security, the decisive design choice is runtime enforcement at the operation boundary, not stronger snapshots.

Runtime enforcement is becoming the practical baseline for mutable workloads. Container filesystems, shared volumes, and CI workspaces create exactly the kind of mutable state that TOCTOU exploits. When the environment allows object substitution after approval, identity and access governance must assume the runtime object can differ from the reviewed one. Practitioners should treat syscall-bound controls as part of the workload trust model, not as an optional hardening layer.

Time-of-use policy reveals a broader governance gap in modern automation. Many security programmes still certify what was true earlier and assume it remains true long enough to matter. That assumption fails for ephemeral, highly mutable systems, including workloads that look compliant at scan time but diverge at execution time. The field needs to shift from evidence of prior safety to enforcement of present safety.

Kernel-bound control points create a more precise trust boundary than userspace checks. By relying on eBPF and Linux Security Module hooks, runtime policy can evaluate the resolved object rather than the attacker-controlled path string. That distinction matters wherever object identity can change during execution, which is why TOCTOU is also an identity governance issue for workloads. Practitioners should align control placement with object resolution, not with user input.

TOCTOU exposes scanner debt in security architectures that overvalue preflight checks. The article’s central lesson is that pre-execution validation remains useful for posture, but it is not sufficient for prevention when runtime mutation is possible. The named concept here is runtime enforcement gap: the distance between a check that passed and a use that should never have trusted it. Close that gap or accept bypass by design.

What this signals

Runtime enforcement gap: security teams should treat every pre-execution validation as incomplete if the underlying object can still change before the operation commits. The practical shift is from proving that a resource looked safe earlier to enforcing that it remains safe at the syscall boundary.

Mutable workloads force identity and access controls to account for object substitution, not just permission state. In container and CI contexts, the attack surface comes from writable paths, symlinks, and rapid file changes, so runtime policy needs to sit where the kernel resolves the object, not where userspace first names it.

For practitioners

• Prioritise runtime enforcement for mutable paths Move policy enforcement to syscall time for file, process, and library operations where the object can change after approval.
• Inventory TOCTOU-prone code paths Review setuid binaries, path-based access checks, and any access() then open() pattern that separates validation from execution.
• Harden container and CI write surfaces Restrict writable volumes, shared workspaces, symlinkable directories, and other mutable paths that let an attacker swap the target object.
• Validate that kernel enforcement is active Confirm the workload is actually covered by Linux Security Module or eBPF policy before relying on runtime controls for prevention.

Key takeaways

• TOCTOU attacks succeed because a valid check can be separated from the later use of the same resource, allowing the object to change underneath the decision.
• Scanners, admission gates, and userspace guards are useful for posture, but they do not stop runtime swapping in mutable environments.
• The control that changes the outcome is enforcement at the syscall, where the kernel evaluates the resolved object at the moment of action.

Key terms

• Time Of Check To Time Of Use: A race condition where a system validates a resource at one moment, then uses it later after the resource may have changed. In security work, TOCTOU weaknesses matter because attackers can swap paths, files, or links between validation and execution. The result is a control that appears sound but can be bypassed in practice.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
• Linux Security Module: A kernel framework that lets security controls make decisions at sensitive operations such as file open or program execution. It is relevant here because the policy hook fires close to time of use, which reduces the opportunity for resource substitution.
• eBPF: eBPF is a Linux kernel technology that lets security tools observe selected system events without modifying the kernel itself. In runtime protection, it is used to watch syscalls, process activity, and host behaviour, which helps detect post-exploitation actions and policy violations.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect identity governance to real-world control decisions across modern security programmes.