Why do scanners and admission controllers miss TOCTOU attacks?

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.

Why This Matters for Security Teams

TOCTOU failures are not a niche programming bug. They are a control gap that appears whenever a security decision is made on one state and the risky action happens on another. That matters for scanners, admission controller, policy engines, and orchestration layers because each can be correct at the moment of evaluation and still wrong at the moment of execution. The result is a false sense of assurance, especially in containerised and automated environments where objects are created, mutated, and consumed quickly.

For security teams, the practical issue is that “pass at check time” is not the same as “safe at use time.” A workload can validate against a clean image, a compliant spec, or an approved path and still execute code, mount content, or inherit permissions that were swapped in after the check completed. This is why defenders need to think in terms of commit-time assurance, not just inspection-time assurance. The underlying attack pattern is consistent with well-known abuse of valid states and timing windows described in the MITRE ATT&CK Enterprise Matrix. In practice, many security teams encounter TOCTOU only after a harmless-looking object has already been replaced with something malicious, rather than through intentional control design.

How It Works in Practice

The mechanics are simple but easy to miss. A scanner evaluates an artifact, such as an image, file, dependency, or configuration snapshot. An admission controller evaluates a request, such as a pod spec, deployment manifest, or policy decision. Both are point-in-time checks. If the object remains stable until use, the control is useful. If an attacker can change the object, redirect a reference, or swap a trusted component after the check, the earlier approval no longer describes what actually runs.

In Kubernetes and similar orchestration stacks, the risk often comes from mutable references, delayed pulls, shared volumes, and race conditions between validation and execution. A secure design reduces that gap by making the checked object immutable, binding identity to content, and enforcing policy again at the point of consumption where possible. Practical defenders usually combine several measures:

• Use immutable image digests instead of mutable tags.
• Restrict write access to manifests, registries, and mounted paths.
• Verify content at pull time, not only at admission time.
• Log and alert on late-stage mutations, retries, and rebinds.
• Apply policy close to the runtime boundary, not only at submission.

This is where scanner findings and control mappings should be treated as evidence, not as proof of runtime safety. Guidance from control frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls supports layered enforcement, but implementation still needs runtime integrity checks and tamper-resistant workflows. These controls tend to break down when the environment allows fast object replacement through shared storage, loosely governed CI/CD pipelines, or controllers that trust mutable references after admission.

Common Variations and Edge Cases

Tighter runtime enforcement often increases operational overhead, requiring organisations to balance stronger assurance against deployment speed and platform complexity. That tradeoff becomes visible in high-churn environments, where teams want rapid rollout, ephemeral workloads, and frequent rebuilds without adding brittle policy steps.

There is no universal standard for this yet, but current guidance suggests treating TOCTOU as a design constraint rather than a detection problem alone. In supply chain scenarios, the issue may not be a container image swap at all. It can be a dependency changed after scanning, a config file updated after validation, or a symlink or mount path redirected just before execution. In AI-adjacent environments, the same timing problem can appear when a policy engine approves a tool, dataset, or prompt source that is later replaced before the agent uses it. That is where the intersection with agentic systems becomes important, and where the attack logic overlaps with adversarial patterns tracked by the MITRE ATLAS adversarial AI threat matrix. For defenders, the safest assumption is that any mutable reference can be abused unless the platform enforces identity, integrity, and timing guarantees together.

Teams often get tripped up in highly automated pipelines because the control is placed upstream of the real risk. When the environment permits mutable artifacts, asynchronous execution, or delayed reconciliation, the snapshot no longer reflects the thing that matters most: the object at the instant it is consumed.

Related resources from NHI Mgmt Group

• Why do image scanners miss some container supply chain attacks?
• Why do file integrity tools miss attacks like Copy Fail?
• Why do static scanners miss some cloud-native attack paths?
• Why do endpoint tools miss so many browser-based account takeover attacks?