The risk comes from time of check, time of use. A path can look safe when it is resolved, then be replaced by a symlink or other filesystem object before privileged actions run. In this case, that allows a low privileged account to redirect ownership changes onto a more sensitive location. Any privileged script that acts on user controlled paths needs atomic validation and use.
How TOCTOU turns a safe-looking path into a privilege boundary break
The core issue is that path resolution and the privileged action are not the same moment. A path can be checked when it points to an acceptable object, then swapped before the privileged user opens, writes, changes ownership, or follows it. That gap lets a low-privileged actor steer a trusted process toward a different target.
The risk is strongest when the privileged script trusts filenames, directories, temp paths, upload locations, or cleanup paths that a user can influence. If the code performs a check and later uses the same string without an atomic open-and-verify pattern, the filesystem itself becomes part of the attack surface.
Why the attacker wants a symlink, rename, or replacement window
Attackers do not need to defeat the original validation if they can change the object after validation. A common pattern is to replace a benign file with a symlink, hard link, bind mount, or renamed object that now resolves somewhere more sensitive, such as configuration files, ownership metadata, or a root-controlled path.
That matters because many privileged operations are decisive even when they look narrow. Changing ownership, truncating a file, appending to a script, or moving a file into place can all become escalation steps when the target is redirected after the check.
On systems with shared directories, cron jobs, installers, backup scripts, or maintenance tooling, this becomes a race the attacker can repeat until they win. The privilege boundary is then enforced by timing, not by design.
What makes this class of bug hard to fix correctly
Defenses fail when teams assume that validating a path string is enough. In practice, the safe object is whatever the kernel resolves at the time of use, so the code must bind the check and the use together. That usually means atomic operations, refusing unsafe traversal, and ensuring the opened object is still the one that was intended.
It also means treating user-writable directories as hostile, even if the operation itself is run by a trusted account. A low-privileged service user may only control one part of the path, but that is enough if the privileged process later follows the path without re-validating the resolved object.
Risk and Threat Considerations
This pattern creates a classic privilege escalation condition because the defender is trusting a value that can change between verification and action. The exploit often succeeds without breaking permissions directly, which makes it attractive in scripts and service workflows that were written for convenience rather than adversarial conditions.
Failure mechanism: a time-of-check, time-of-use gap lets an attacker replace or redirect the file object after validation, so the privileged process acts on a different target than the one it approved.
Impact: low-privileged users can convert an ordinary filesystem interaction into unauthorized writes, ownership changes, or modification of sensitive files, which can become full host compromise when the target is security-critical.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1574 — Hijack Execution Flow | Covers path hijacking and object replacement used to redirect privileged execution. |
| Recommendation — Map the race to T1574-style hijacking and hunt for privileged file-handling paths. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Privilege minimisation reduces the blast radius when filesystem races are exploited. |
| SI-10 — Information Input Validation | Input validation must include filesystem references that influence privileged actions. | |
| Recommendation — Apply AC-6 to limit privileged file operations to the minimum required scope. Validate filesystem inputs before privileged use and reject unsafe path traversal patterns. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | Race-condition weaknesses in privileged tooling are technical vulnerabilities requiring control. |
| Recommendation — Track and remediate TOCTOU-prone file-handling code as a technical vulnerability. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Hardening privileged scripts and file permissions reduces exposure to path-replacement attacks. |
| Recommendation — Harden privileged services and file permissions to prevent user-controlled path abuse. | ||
Practitioner Guidance
What to verify: confirm whether the privileged code opens the file atomically and validates the resolved object, not just the path string. If the workflow uses temporary files, cleanup routines, or ownership changes, inspect every step that reuses user-controlled filesystem references.
What good looks like: privileged operations either fail closed on unsafe path patterns or use kernel-enforced atomic patterns that prevent a swapped object from being substituted between check and use. The safest design is to minimise privileged file handling in the first place, especially in shared or writable directories.
Practitioner takeaway: if a low-privileged user can influence the path, assume the object can be replaced until the privileged operation is complete, and design the code so the check and the use are inseparable.
Related resources from NHI Mgmt Group
- Why do low integrity processes still create meaningful privilege escalation risk?
- Why do service accounts with standing IAM privilege create escalation risk in cloud environments?
- Why does Azure elevate access create such a high-risk privilege escalation path?
- Why do improperly secured service communication paths create local privilege escalation risk on Windows endpoints?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
