Link Following is a weakness where software follows a symbolic or hard link to a file or directory that an attacker controls. This can redirect reads, writes, or deletes to unintended targets, including sensitive system files. Defenders should avoid unsafe link traversal and verify the final resolved path before use.
What Link Following Means in Practice
Link following is dangerous because the path name a program checks is not always the file it actually accesses. An attacker can swap or control a symbolic or hard link so the software operates on an unintended target, turning an ordinary file operation into a security boundary bypass.
The weakness matters most when the software treats a path as trusted before resolving it fully. That can let reads leak sensitive content, writes corrupt protected files, or deletes remove the wrong object entirely.
Why Unsafe Link Traversal Becomes a Security Problem
File handling code is often written with a simple assumption: if a pathname is allowed, the referenced object is safe. Link following breaks that assumption because the visible path and the final resolved target can differ after the check, especially in directories an attacker can influence.
That gap is what makes the weakness a classic time-of-check, time-of-use problem. The application may validate a location, then follow a link that changes the effective destination before the operation occurs.
In practical terms, the risk is not just accidental misdirection. It can expose configuration files, logs, credentials, or other sensitive data if the program reads through a malicious link, or it can damage system files if it writes or deletes through one.
How Defenders Reduce Exposure to Link Following
Mitigation starts with treating path resolution as part of security validation, not just string handling. Programs should verify the final resolved path before use, avoid following links in attacker-controlled locations, and prefer file APIs that can operate safely on descriptors or explicitly constrained directories.
Defensive design also needs to account for race conditions. Even if a path is validated at one moment, an attacker may change the filesystem object before the operation completes, so validation must be paired with atomic or link-safe handling wherever possible.
For development teams, this is a secure coding issue as much as an operational one. The right control is to remove unsafe assumptions about path equivalence and to make the intended target, not the user-supplied pathname, the basis for access decisions.
Common Failure Modes and Real-World Consequences
Link following weaknesses usually appear in temporary file handling, cleanup routines, privileged maintenance jobs, and any code that touches attacker-influenced directories. The problem becomes more severe when the process runs with elevated privileges, because the link can redirect privileged file operations into protected areas.
Because the weakness changes the actual object being accessed, its impact can range from data exposure to integrity loss and service disruption. A small mistake in path handling can therefore become a broad filesystem trust failure.
For a broader taxonomy of dangerous software flaws, the CWE Top 25 Guide is a useful reference point for understanding how link-following weaknesses sit alongside other high-impact implementation errors.
Risk and Threat Considerations
Link following is especially risky where an attacker can create or replace filesystem objects in a location the software trusts. The weakness is attractive because it can turn a routine file access into unintended access to sensitive targets, often without needing to break authentication or exploit memory safety.
Failure mechanism: The application validates or constructs a pathname, then follows a link to a different final object after the check, allowing the attacker to redirect the operation to a protected file or directory.
Impact: Confidential data may be read, critical files may be overwritten or deleted, and privileged processes may be abused to modify objects the attacker could not normally touch.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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-16 — Application Software Security | Link following is a secure coding weakness in application file handling. |
| Recommendation — Review file-handling code for unsafe pathname trust and enforce secure coding patterns. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Final path resolution and trusted-object checks depend on validating attacker-controlled input before use. |
| Recommendation — Validate and constrain file paths before any privileged file operation. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Unsafe link traversal is a software design and implementation flaw in path handling logic. |
| Recommendation — Design file access paths so operations use resolved trusted targets, not raw user-supplied paths. | ||
Practitioner Guidance
Why practitioners should care: Any code that accepts attacker-influenced paths should be reviewed as a potential privilege boundary, not just a file utility. The unsafe case is usually not the file operation itself, but the assumption that a path string still names the same object after validation.
What to watch for: Temporary directories, cleanup scripts, upload handlers, and privileged maintenance tasks are common places where link traversal mistakes surface. Pay special attention when the process can write, delete, or chown files in shared or writable locations.
Practitioner takeaway: Treat final-path verification and link-safe file handling as mandatory whenever the target path is not fully trusted, especially in code that runs with elevated permissions.