UNIX Hard Link is a directory entry that points to the same underlying file data as another name on the same filesystem. If applications trust file names instead of checking the target, attackers can use hard links to overwrite or access sensitive files. Defenders should verify inode and ownership before acting on files.
What a UNIX hard link actually changes
A UNIX hard link is not a copy of a file, it is another directory entry for the same inode. That means two or more names can reference the same underlying data, so changes through any name affect the same file object.
This matters because security decisions based only on a pathname can be fooled. If software assumes a file name uniquely identifies a safe target, the link relationship can redirect that trust to a different file on the same filesystem.
Why hard links are security-sensitive
Hard links are dangerous when privileged code opens, truncates, writes, or deletes files without verifying what the name resolves to. A process may think it is handling an ordinary temporary or working file, while actually acting on a sensitive target that shares the same inode.
The classic failure mode is race condition through link following, where code checks a path too early or too narrowly and then performs a privileged action on the wrong object. Hard links are especially relevant in local privilege escalation and file overwrite scenarios because they exploit the gap between name-based checks and object-based reality.
Defenders should treat hard links as part of the broader class of path confusion problems, and they should verify inode, ownership, permissions, and expected file type before trusting any file that a privileged process will modify.
How UNIX hard links differ from symbolic links
A hard link points directly to the same inode, while a symbolic link stores a separate pathname that is resolved at access time. That difference changes both behavior and risk: hard links stay valid as long as the inode exists on the same filesystem, while symbolic links can cross pathname boundaries and point elsewhere.
Because hard links are tied to filesystem semantics rather than string resolution, they can survive simple pathname-based checks. That is why secure file-handling code must reason about the underlying object, not just the text of the path supplied by a user or another process.
In practice, hard links also have operational limits that matter for security review. They usually cannot span filesystems and they do not create a new copy of the content, so any control that assumes “new name means new file” is incomplete.
Where hard links fit in secure file handling
Hard links become a security concern wherever software creates, opens, or replaces files in locations that an attacker can influence. Temporary files, log files, spool directories, backup workflows, and privileged maintenance jobs are common places where link confusion can become exploitable.
Secure handling starts with object-aware validation. A privileged program should not rely on the filename alone; it should verify that the file it is about to use is the expected inode, belongs to the expected owner, and has not been substituted through a link relationship.
When the filesystem design or application workflow makes that verification difficult, the safer pattern is to reduce the privilege of the process, isolate writable locations, and avoid operating on attacker-controlled paths altogether.
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-3 — Data Protection | Hard links can redirect privileged file operations onto sensitive data. |
| Recommendation — Harden file handling paths and restrict write access to sensitive directories. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The issue arises when file paths and targets are not validated before use. |
| AC-6 — Least Privilege | Privilege amplifies the impact of link-based file confusion. | |
| Recommendation — Validate file targets and reject unsafe path-based inputs before privileged file operations. Limit file-handling privileges so a mistaken path cannot overwrite high-value files. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Secure file access requires object-aware handling and defensive design against link confusion. |
| Recommendation — Design file operations to verify the target object, not just the submitted name. | ||
| MITRE ATT&CK | T1222 — File and Directory Permissions Modification | Adversaries abuse filesystem semantics to alter access to files and directories. |
| Recommendation — Map suspicious file-system access patterns to filesystem abuse techniques and hunt for privilege escalation. | ||
Practitioner Guidance
What to watch for: Review any code or script that runs with elevated privileges and touches files in shared, temporary, or user-influenced directories. The key question is whether the program trusts a path string more than the underlying file object.
Practitioner takeaway: If a process can be tricked into acting on the wrong inode, the security bug is usually in the file-handling logic, not the link itself. Use object-level checks and conservative filesystem access patterns wherever privilege is involved.