A UNIX hard link issue occurs when a file is linked in a way that lets one pathname point to the same underlying inode as another. Attackers can exploit hard links to bypass permission checks, preserve access to sensitive content, or confuse cleanup logic. Defenders restrict link creation, verify ownership and permissions, and avoid unsafe assumptions about path names.
What makes a UNIX hard link issue happen?
A hard link issue starts when the same inode is reachable through more than one pathname. That is normal Unix behaviour, but it becomes dangerous when software treats the name as the security boundary instead of checking the inode, ownership, and permissions. The problem is usually not the link itself, but the assumptions made about which path is safe.
Hard links are most problematic in code that opens, moves, cleans up, or validates files based on pathname alone. If a privileged process follows a pathname without verifying what object it actually references, an attacker can substitute or preserve access to content that the code meant to protect. That is why path-based checks are fragile when the underlying object can be linked from elsewhere.
For a deeper view of the weakness patterns behind this class of bug, the CWE Top 25 Guide is useful because it groups file-system mistakes with broader software weakness patterns such as path handling, authorization failures, and race-prone assumptions.
Why hard links become a security problem
The core security issue is that a hard link can preserve access to sensitive data even when one pathname looks harmless or has been moved into a different part of the file tree. If a program only checks whether the visible path seems acceptable, it may miss the fact that the inode is shared with a protected file. That can lead to permission bypass, unintended disclosure, or destructive cleanup of the wrong object.
Cleanup and lifecycle code are especially exposed. A script that deletes files by name, rotates logs, or archives temporary content may act on a hard link that points to a different object than the code expected. The risk rises when the process has elevated privileges, because the attacker does not need to break the permission model directly, only to make the privileged program act on the wrong target.
Defense is stronger when the system treats file identity as more than a string. MITRE D3FEND Guide is relevant here because it frames local file access mediation, file permission checks, and object verification as defensive techniques rather than relying on pathname trust.
How to prevent and verify safe handling
Hard-link issues are reduced by constraining who can create links, separating privileged and unprivileged file areas, and verifying ownership and permissions before acting on a file. On Unix-like systems, the practical rule is to distrust the path until the object behind it has been checked. That means validating the target, avoiding assumptions about uniqueness, and refusing cleanup logic that can be redirected through shared inodes.
Where the code must handle files in sensitive directories, use safe file-handling patterns that do not rely on simple name checks. Review any routine that removes, overwrites, or renames files, because those are the places where a shared inode can turn a routine maintenance action into an access-control failure. If the application manipulates files created by less-trusted users, treat link handling as part of the security design, not a filesystem edge case.
Operationally, hard-link safety belongs alongside baseline Unix hardening. The CIS Benchmarks are useful for aligning file-system, privilege, and secure configuration practices with the platform baseline that the workload actually runs on.
Risk and Threat Considerations
Hard links become risky when privileged code trusts a pathname more than the inode and its permissions. That can let an attacker preserve access to sensitive content, redirect cleanup logic, or cause a trusted process to act on a file it never intended to touch.
Failure mechanism: A program performs authorization, ownership checks, or cleanup decisions on the name it sees, but the same inode is reachable through another link that changes the practical security meaning of that name. In race-prone or privileged workflows, that lets an attacker exploit a mismatch between the checked path and the actual object.
Impact: The result can be unauthorized read access, accidental deletion or modification of protected data, or a control bypass in software that assumes file paths are unique, stable, or harmless.
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, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | File-link abuse is reduced by controlling privileged and shared account use. |
| Recommendation — Restrict account use that can create or act on sensitive links. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Hard links can bypass path-based checks, so access must be enforced on the object. |
| Recommendation — Enforce access decisions on the underlying object, not the pathname. | ||
| OWASP ASVS | V5 — File Handling | Safe file handling must account for inode sharing, ownership checks, and cleanup behavior. |
| Recommendation — Validate file targets before destructive or privileged file operations. | ||
| MITRE ATT&CK | T1222.002 — File and Directory Permissions: Linux and Mac File and Directory Permissions | Hard link abuse is a Unix file-permission abuse pattern that can support unauthorized access. |
| Recommendation — Hunt for permission abuse and anomalous access to linked files. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Management | Hard link abuse exploits weak access assumptions around file objects and privileged actions. |
| Recommendation — Apply least-privilege access controls around file-creating and file-cleanup processes. | ||
Practitioner Guidance
What to verify: Review any code path that opens, deletes, rotates, or archives files and confirm that it checks object identity, ownership, and permissions rather than trusting pathname labels alone. Pay special attention to privileged utilities and maintenance jobs.
Common mistake: Treating “not a symlink” as equivalent to “safe”. Hard links do not need symlink semantics to create a security problem, so checks must cover inode sharing and file ownership as well as path structure.
Practitioner takeaway: A hard link issue is fundamentally a trust-boundary problem, so the safest response is to reduce who can create links, verify the object behind the path, and avoid file operations that assume names are authoritative.
Related resources from NHI Mgmt Group
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.
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