What causes UNIX symbolic link following?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Cyber Security

UNIX symbolic link following is caused by file-handling code that does not stop the operating system from resolving a symbolic link to another target. That lets an attacker redirect reads or writes to unexpected files, including sensitive system or application data. Use file-opening patterns that avoid following links and verify the resolved target before use.

How UNIX symbolic link following happens

symbolic link following is a path resolution behaviour, not a special feature an attacker has to invent. When code opens or writes a path and the operating system is allowed to resolve links normally, the symlink is treated as a pointer to its target. If the program assumes the path names the intended file, the resolved target can be different from the one the developer expected.

This matters most when the application trusts a pathname before the final open, because the pathname and the object actually accessed can diverge. The weakness usually sits in file-handling logic that checks a path, then uses it later, or in code that never constrains the file-open operation to a safe object type. That is why symlink following is often discussed alongside race conditions and unsafe temporary-file handling.

For a broader view of how this weakness fits into common software weaknesses, the CWE Top 25 Guide helps place path-handling mistakes in the wider weakness landscape, while the NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control vocabulary practitioners use when file access must be constrained and monitored.

Why it turns into an access-control problem

The immediate consequence is not just “a link was followed”, but “the process may have operated on the wrong object”. In practice, that can turn an ordinary read or write into access to a sensitive file, configuration file, log file, or application secret store, depending on the privilege of the process and the location of the link target.

Because the operating system resolves the link at access time, the real security question becomes whether the program mediated the final target, not just the original pathname. Safe handling usually means opening the file in a way that rejects symlinks where they are not expected, constraining directory traversal, and confirming the resolved target before any sensitive read or write. The OWASP API Security Top 10 is useful here as a reminder that broken object access is often about trusting an identifier or path more than the eventual object behind it.

On systems where attacker-controlled files or directories are involved, the issue can become a local privilege escalation path. The attacker does not need to break the filesystem, only to place a link where the program will later trust it. That is why the weakness is often exploited in scripts, utilities, installers, cleanup jobs, and privileged service code.

Where defenders should focus first

The most reliable fix is to design file handling so the program does not rely on a path alone when the target matters. Open the object with link-safe patterns, operate on the already-open file descriptor where possible, and verify ownership, type, and location before any privileged action. Avoid code paths that check first and open later, because that creates a window for the target to change.

When you have to allow links in some contexts but not others, separate trusted and untrusted directories, lock down permissions on parent directories, and treat temporary files as security-sensitive objects. The same discipline applies to services running with elevated privileges, because their failure mode is more severe: a redirected write can overwrite a config file, a startup script, or another security-relevant artifact.

The NIST Cybersecurity Framework 2.0 is a useful high-level reference for governance and protective practices, while the CIS Benchmarks provide hardening guidance that often reduces the attack surface around risky file paths and privileged file access.

Risk and Threat Considerations

Symlink following becomes dangerous when an attacker can influence a pathname that privileged code will later open. The risk is highest in setuid programs, services running as root or another powerful account, and workflows that create, clean up, or process files in writable locations.

Failure mechanism: The program trusts the name of the file rather than the final object, so the operating system resolves a symbolic link to a different target at access time. If the attacker can place or swap the link between checks and use, reads or writes land on a file the program never intended to touch.

Impact: The process may leak sensitive data, overwrite critical files, corrupt application state, or grant an attacker a path to broader privilege abuse. In a privileged context, this can become full system compromise or durable persistence if the redirected write changes configuration or execution paths.

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-4 — Secure Configuration of Enterprise Assets and Software	Symlink-safe file handling depends on hardened system and software configuration.
Recommendation — Harden file paths, permissions, and privileged services to reduce unsafe link-following exposure.
NIST SP 800-53 Rev 5	AC-3 — Access Enforcement	Controlling which file objects a process may access is central to symlink-following risk.
	CM-7 — Least Functionality	Reducing unnecessary file access and features limits opportunities for unsafe link traversal.
Recommendation — Enforce file access decisions at the object level, not only at the pathname level. Remove unnecessary file-handling paths and capabilities that can be abused through symlinks.
OWASP ASVS	V13 — Configuration	Secure file and path configuration helps prevent unexpected target resolution.
Recommendation — Configure file access and deployment paths so untrusted links cannot redirect sensitive operations.
MITRE ATT&CK	T1036 — Masquerading	Path deception and redirected access are often used to disguise the real object being touched.
Recommendation — Map deceptive path behaviour to ATT&CK and hunt for suspicious file redirection patterns.

Practitioner Guidance

What to verify: Confirm that the code uses link-safe open patterns and that any privilege-bearing file access is validated at the point of use, not only before the call. If the file can be attacker-influenced, assume a symlink can be introduced unless the code explicitly prevents it.

Common mistake: Developers often validate the pathname, then assume the target is safe for the rest of the operation. That assumption fails whenever the target can be swapped, inherited, or placed in a writable directory.

Practitioner takeaway: Treat symbolic link following as a target-selection problem, not just a filesystem quirk, and build the control so the program proves it is operating on the intended object before any sensitive action.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org