What causes link following?

Link following is caused by code that opens or checks a file path without preventing symbolic or hard link resolution. An attacker can replace the target with a link to a sensitive file and make the program read, modify, or delete the wrong object. Defenders should resolve paths safely and refuse unexpected links where appropriate.

What link following actually is

Link following happens when a program opens, reads, writes, or deletes a path and trusts that path to still refer to the intended file. If an attacker can swap in a symbolic link or hard link, the program may act on a different target than it expected. The core mistake is treating path names as stable identities.

The problem is especially important anywhere software handles temporary files, cleanup paths, logs, uploads, or privileged maintenance tasks. A safe path check must verify the final object, not just the string the program was given.

Why symbolic links and hard links make it dangerous

A symbolic link points to another pathname, while a hard link gives another name to the same underlying file. Both can defeat naïve checks that only inspect the original filename. If code follows links without restriction, a lower-privileged user can redirect sensitive operations toward files the application should never touch.

That is why safe handling often needs both path resolution rules and ownership or type checks. The important question is not only “does this path exist?”, but “what object will the operating system actually resolve here, and is that object acceptable for this operation?”

Attackers look for code that creates a file and later reopens it, or code that checks a path and then uses it after a delay. That gap creates a window where the target can be replaced, renamed, or relinked. In practice, link following often appears alongside race conditions and insecure temporary file handling.

How to prevent it in code and operations

The defensive pattern is to resolve paths safely and to refuse unexpected links where the business process does not require them. That usually means using safer open flags, validating the final file type, and ensuring the target stays within the expected directory or trust boundary. When possible, operate on file descriptors rather than reopening by name.

When an application must process user-controlled paths, the safest design is to treat links as untrusted input unless there is an explicit, reviewed reason to allow them. If the workflow involves privileged code, the bar should be higher: the program should not inherit a user’s ability to redirect a sensitive operation through a link.

For programs that must safely create or update files, the right control is to combine atomic file creation with strict path and permission checks. That reduces the chance that a file created for one purpose is later redirected to another object through a link swap.

Risk and Threat Considerations

Link following can turn an ordinary file operation into arbitrary read, overwrite, or deletion of a sensitive object. The risk is greatest when privileged software touches attacker-influenced paths, because a simple filesystem trick can become a high-impact integrity or confidentiality failure.

Failure mechanism: The program checks a pathname, then the attacker replaces that pathname with a symbolic or hard link before the sensitive file operation occurs, causing the code to act on the wrong object.

Impact: Sensitive files can be disclosed, corrupted, or deleted, and if the target is a credential, config, or executable file, the blast radius can extend beyond the original application.

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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1190 — Exploitation for Client Execution	Link following is an exploitation pattern involving attacker-controlled file paths.
Recommendation — Map path abuse to exploitation techniques and hunt for unsafe file handling in privileged code.
CIS Controls v8	CIS-5 — Account Management	Safe file access depends on limiting what privileged processes can touch and under which accounts.
Recommendation — Restrict privileged file operations to the minimum accounts and permissions needed.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Limiting privilege reduces the impact when a link redirects a file operation to a sensitive object.
Recommendation — Apply least privilege so file-processing services cannot act on sensitive paths they do not need.

Practitioner Guidance

What to verify: Confirm whether the code ever reopens a file by path after an initial check. If it does, verify that the final object is still the expected file, directory, or device, and that link handling is intentional rather than accidental.

Decision rule: If the path can be influenced by a less-trusted user or process, treat link following as a security boundary and block it unless the use case explicitly requires links. If the operation is privileged, assume the attacker will try to win a race between the check and the use.

What good looks like: The code performs sensitive file operations on verified objects, not merely on trusted-looking path strings, and the surrounding process does not depend on path reuse across separate checks.

Practitioner takeaway: Link following is a path trust problem, not just a filesystem quirk, so the safest fix is to remove ambiguity between the name you inspect and the object you actually operate on.