UNIX Symbolic Link (Symlink) Following is a weakness where a program follows a symlink to a different file than intended. An attacker can redirect file access to overwrite, read, or delete protected content, especially in temporary or writable directories. Defenders should check the resolved target and avoid unsafe file operations on links.
How symlink following creates file integrity risk
A symlink turns one pathname into a pointer to another object. The danger appears when a program assumes the visible path is the real target and then performs a sensitive action on the resolved file, creating a mismatch between intended and actual access.
This is especially dangerous in writable or shared locations such as temporary directories, upload areas, spool paths, and caches. If an attacker can place or replace a link there, the program may write into protected files, disclose data it should not read, or delete content it never meant to touch.
Where symlink following becomes exploitable
The weakness usually depends on a race, a trust boundary failure, or both. A check that looks safe at one moment can be invalid a moment later if the link is swapped before the file operation completes. That is why this issue is often discussed alongside time-of-check and time-of-use flaws.
Privilege separation makes the outcome worse when a low-privilege user can influence a path that a higher-privilege process later opens. The process is not being tricked by the filename alone, it is being tricked into operating on a different inode, device, or directory tree than the code author expected.
Common failure modes and safe handling patterns
Unsafe patterns include creating files without checking whether the path is a link, opening a pathname before validating the resolved target, and performing destructive operations in directories that untrusted users can modify. Symlink handling must be explicit because ordinary path checks do not automatically protect against link traversal.
Safer designs resolve the final target, reject unexpected link traversal, and use file operations that avoid following links when the platform supports them. Programs should also constrain file creation to controlled directories and treat temporary files as security-sensitive objects, not convenience artifacts.
Why this weakness matters in real systems
Symlink following can expose configuration files, logs, credentials, and application state, depending on what the privileged process is allowed to touch. In backup jobs, installers, cleanup tasks, and automation scripts, a single mistaken write or delete can become a high-impact integrity incident.
The problem is not limited to classic UNIX filesystems. Any environment that mixes privileged automation with attacker-influenced paths can inherit the same failure pattern, especially where directory permissions, ownership, and path validation are inconsistent.
Risk and Threat Considerations
Attackers use symlink following to redirect a trusted program into reading, overwriting, or deleting a protected file. The risk is highest when a privileged process works in an attacker-writable directory or when path validation and file use are separated by a race window.
Failure mechanism: The program validates the name or directory, then later follows a changed link and operates on an unintended target, often with elevated privileges.
Impact: This can lead to configuration tampering, data disclosure, destructive file modification, or denial of service, and in some cases it can become a stepping stone to broader system compromise.
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 and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Symlink following often abuses file access paths and privilege boundaries that account and access controls must constrain. |
| Recommendation — Restrict privileged file operations to trusted accounts and minimize access to writable directories. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege limits the damage when a privileged process is tricked into following an unintended path. |
| SI-10 — Information Input Validation | This weakness arises when software fails to validate the resolved file target before acting on it. | |
| CM-7 — Least Functionality | Reducing unnecessary write/delete behavior and exposure in shared directories lowers the attack surface for link-following abuse. | |
| Recommendation — Limit file-system privileges so a path traversal mistake cannot modify protected content. Validate file paths and resolved targets before any sensitive file operation. Remove unnecessary file-write capabilities from processes that handle untrusted paths. | ||
| OWASP ASVS | V5 — File Handling | File-handling requirements directly cover safe opening, creation, and validation of files and links. |
| Recommendation — Apply secure file-handling checks before opening or modifying files in attacker-influenced locations. | ||
| MITRE ATT&CK | T1070.001 — File Deletion | Symlink abuse can be used to trigger unintended deletion of files through trusted processes. |
| Recommendation — Map suspicious deletion activity to link-following abuse when trusted processes act on shared paths. | ||
Practitioner Guidance
What to watch for: Review any code path that opens, creates, truncates, renames, or deletes files in shared locations, especially when those paths can be influenced by users, jobs, containers, or other automation. The highest-risk cases are privileged services that assume a pathname is trustworthy because it was checked earlier.
Governance implication: Treat symlink handling as part of secure file handling policy, not as a one-off coding mistake. Teams should standardize safe file APIs, directory permissions, and review rules so that link traversal is considered wherever file operations cross trust boundaries.