TOCTOU attacks bypass scanners by design, not by chance

At a glance

What this is: This is an analysis of TOCTOU race conditions and the claim that runtime enforcement, not scanning, is the control that closes the attack window.

Why it matters: It matters because identity and access controls fail when they rely on stale validation, especially in privileged workflows, workload execution paths, and NHI-adjacent policy enforcement.

👉 Read AccuKnox's analysis of TOCTOU attacks and runtime enforcement

Context

TOCTOU, or time-of-check to time-of-use, is a race condition where a system validates a resource, then acts on it later. The core governance problem is that many controls make a decision once and assume the object remains unchanged. In workload and privileged-access environments, that assumption can be broken by a process that swaps the target between validation and execution.

This creates an important identity and access angle for IAM and PAM teams because the failure mode is not just weak authentication. It is stale authorisation for the object that is actually used. The article argues that scanner-based and admission-time controls are structurally limited, while runtime enforcement makes the decision against the resolved object at use time.

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 and admission controllers miss TOCTOU attacks?

A: They evaluate a snapshot. A scanner sees what existed at scan time, and an admission controller sees the workload spec at scheduling time. TOCTOU exploits the later window, after the control has already finished. If the object can be swapped before the operation commits, the earlier check cannot provide assurance for the actual use.

Q: How should teams reduce TOCTOU risk in privileged workflows?

A: Prioritise runtime enforcement for any workflow that resolves a path and then acts on it, especially in setuid code, CI jobs, container mounts, and file-handling automation. Remove split validation patterns where possible, and place policy at the kernel or syscall layer so the object checked is the object used.

Q: What is the difference between time-of-check and time-of-use enforcement?

A: Time-of-check enforcement approves a resource before execution, while time-of-use enforcement evaluates the resolved object at the moment the operation actually runs. The first can be bypassed by substitution, the second closes that window. In mutable environments, that difference determines whether a check is advisory or binding.

Technical breakdown

Why TOCTOU is a race condition, not a scanning failure

TOCTOU exists because the system performs two separate steps. First it checks whether a path, file, or resource is acceptable, then it uses that resource later. If an attacker can alter the object, or redirect the name to a different object, between those two moments, the original check is no longer relevant. This is why scanner outputs, manifest checks, and admission decisions can all be accurate and still fail in practice. They are correct for the moment they inspected, but they are not bound to the object that is eventually acted on.

Practical implication: Treat any control that checks once and trusts later as bypassable unless the final use is also enforced.

Why userspace checks fail against symlink swaps and file races

The classic TOCTOU pattern uses a name-to-object mismatch. A program checks a pathname with a permissions call, then opens that same pathname later. An attacker can replace the target with a symlink or otherwise change the mapping so the privileged process acts on a different object than the one it verified. This is why file paths in shared volumes, CI workspaces, container filesystems, and setuid workflows are high-risk surfaces. The risk is not just malicious intent. It is that the validation and the action are separable, so the attacker only needs a brief execution window.

Practical implication: Review privileged file operations that split permission checks from open, write, or execute calls.

How eBPF and BPF-LSM move policy to time of use

Linux Security Module hooks fire inside the kernel at the point a sensitive operation is about to commit. With eBPF and BPF-LSM, policy is evaluated after the kernel resolves the real object, so the decision applies to what the system will actually touch, not what a user supplied earlier. That changes the security model from snapshot validation to runtime enforcement. The article's core point is that the check and the use become the same event, which removes the race window that TOCTOU relies on. This is a kernel-level control pattern, not a stronger scan.

Practical implication: Use runtime enforcement for sensitive file, execution, and rename operations where object substitution would matter.

Threat narrative

Attacker objective: The attacker wants a privileged process to act on an unsafe object while believing it already validated a safe one.

1. Entry begins when an attacker can influence a file path, shared volume, or writable workspace that a privileged process will later touch.
2. Escalation occurs when the attacker swaps the checked resource for a different object, such as a symlink target, after validation but before use.
3. Impact follows when the privileged process performs the operation on the substituted object and writes, executes, or loads something it never intended to trust.

NHI Mgmt Group analysis

TOCTOU is really an authorisation timing problem, not a detection problem. The article is correct that scanners and admission checks can only speak for the object they saw at a point in time. That is a poor fit for privileged workflows where the object can change before use. For IAM and PAM teams, the deeper lesson is that the control must bind to the object at the moment of execution, not to the request that named it.

Runtime enforcement is a policy boundary, not a better alerting layer. The value of kernel-level enforcement is that it removes the attacker’s opportunity to change the target after approval. That is a different security function from monitoring or scanning. In identity governance terms, this is the same design problem that appears whenever standing trust is evaluated too early and consumed too late. The practitioner conclusion is that time-of-use controls belong wherever object substitution would defeat a prior check.

Named concept: check-use drift. This article shows how control decisions drift away from the object they are supposed to protect when validation happens earlier than execution. Once that drift exists, any workload, script, or privileged helper that resolves names and acts later is exposed to substitution. The governance implication is clear: controls must be measured by whether they remain attached to the resolved object, not by whether they completed a preflight step.

TOCTOU is especially relevant wherever non-human identities execute privileged actions. Service accounts, automation jobs, and platform helpers often run with permissions humans do not watch closely, which makes race windows harder to notice and easier to exploit. That does not mean the identity is the flaw. It means the operational model around that identity is assuming a stable target when the environment is mutable. Practitioners should treat ephemeral execution paths as enforcement problems, not just access problems.

Container and CI environments expand the race surface because they normalise mutable paths. Shared volumes, pipeline workspaces, and layered filesystems create the exact conditions TOCTOU needs. The security takeaway is that modern infrastructure can multiply race opportunities even when credentials are tightly controlled. Teams should therefore align runtime policy with the actual object resolution path, not the user-facing name or pre-deployment snapshot.

What this signals

Check-use drift will matter more as infrastructure becomes more dynamic. Teams that rely on pre-deployment validation will keep missing the point of compromise because the real risk sits in the interval between approval and execution. Runtime policy needs to be part of the operating model, not an exception path used only for high-risk workloads.

For identity programmes, the practical shift is toward enforcing trust at the point of action. That means service accounts, pipeline identities, and automation helpers should be governed as execution identities with controls that bind to the resolved object, not just the authenticated session. The article's lesson maps cleanly to runtime assurance, not static approval.

Controls aligned to the MITRE ATT&CK Enterprise Matrix should treat file substitution, symlink races, and path-based abuse as operationally distinct from simple credential theft. The implication for practitioners is to test whether their current policy stack can still stop a malicious swap after the first check has already passed.

For practitioners

• Enforce controls at the syscall boundary Move policy decisions to file_open, bprm_check_security, and related kernel hooks so the resolved object is checked at use time, not in a preflight scanner.
• Audit privileged code for split-check patterns Find any access-then-open, stat-then-write, or validate-then-execute workflow in setuid programs, scripts, and automation jobs, then remove the time gap.
• Restrict writable substitution paths Lock down shared volumes, CI workspaces, and other mutable paths that let an attacker redirect a trusted filename to a different object.
• Map TOCTOU risks to identity governance Treat workload helpers and service accounts as execution identities whose trust must be enforced where they act, not merely where they authenticate.

Key takeaways

• TOCTOU succeeds because many controls approve a resource before the operation actually consumes it.
• The attack surface is widest in privileged workflows, mutable file paths, container volumes, and CI workspaces.
• Binding policy to the resolved object at syscall time is the control that closes the race window.

Key terms

• Time-Of-Check/Time-Of-Use Flaw: A race condition where a system validates something, then later acts on a value that can change in the meantime. In agent systems, this can turn a trusted file path or command into an unsafe action, creating escapes, tampering, or persistence.
• 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.
• Symlink Swap: A substitution technique where an attacker changes a trusted pathname to point at a different object through a symbolic link. In TOCTOU attacks, this lets a process approve one target and act on another, which can turn a harmless file operation into privilege abuse.

What's in the full article

AccuKnox's full article covers the operational detail this post intentionally leaves for the source:

• How the eBPF and BPF-LSM hooks are used to enforce policy at the kernel boundary
• The specific file-open, execute, and symlink hooks that matter for TOCTOU prevention
• A comparison table showing scanner, admission, and runtime enforcement decisions
• Hands-on walkthrough content for KubeArmor deployment across Kubernetes, VMs, and bare metal

👉 AccuKnox's full article covers the kernel hook mechanics, control comparison, and runtime enforcement details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It helps practitioners connect identity controls to the runtime environments where access decisions are actually consumed.