Hard Link Attack is a file-system abuse technique that uses hard links to make one file name point to another inode. Attackers use it to confuse cleanup, access control or log handling logic, especially where software trusts the visible path rather than the underlying file object.
What a hard link attack does
A hard link attack abuses the fact that multiple directory entries can point to the same inode. The visible path may look harmless or temporary, while the underlying file object is the one the attacker actually wants software to touch.
This matters because many workflows make decisions from filenames, directory locations, or path filters rather than from the file object itself. When that gap exists, cleanup routines, log handlers, permission checks, and update logic can be steered toward the wrong target.
Why hard links are dangerous
Hard links are not just another filename alias. They create a second path to the same data, which means the same underlying content can inherit a different context in the eyes of the application, the user, or a background task.
That difference becomes dangerous when software assumes that a file in a “safe” location is safe to process, delete, or overwrite. The hard link lets an attacker preserve access to an object after the original pathname is gone, or redirect maintenance logic toward content that was never meant to be handled in that code path.
Where the confusion usually comes from
Hard link attacks tend to succeed where trust is placed in the path string instead of the file object. Common failure points include temporary-file handling, cleanup jobs, log rotation, archive extraction, and any code that checks a pathname once and then acts on it later.
The deeper issue is a mismatch between name-based reasoning and object-based reality. If the program validates one path, but later opens, truncates, or deletes by name again, an attacker may replace the expected object relationship in between those steps or pre-create a hard link that changes what the operation really affects. The CWE Top 25 Guide is useful here because this class of weakness sits alongside other file-system and race-condition failures that stem from trusting the wrong abstraction.
Defensive patterns that reduce exposure
Defenses work best when they bind the operation to the intended file object, not just the path text. Robust handling usually combines object-safe file APIs, strict temporary-file practices, ownership and permission checks, and logic that avoids reopening a file after validation unless the code can revalidate the exact object state.
On Unix-like systems, this often means treating hard links as part of a broader file-integrity problem, not a narrow filename problem. Safe design also includes limiting where privileged processes read, write, or delete files, because the impact of a mistake is much higher when elevated code follows attacker-controlled link relationships. The MITRE D3FEND Guide is a useful companion for thinking about file validation, access mediation, and hardening controls that reduce this kind of misuse.
Risk and Threat Considerations
Hard link attacks are most dangerous when privileged software performs file operations in attacker-influenced directories or on attacker-influenced names. The attacker does not need to break the file system, only to exploit the gap between what the software thinks a pathname refers to and what the kernel actually resolves.
Failure mechanism: The program trusts a visible pathname or performs a time-of-check to time-of-use sequence that can be redirected through a hard link, causing deletion, overwrite, or logging logic to act on the wrong inode.
Impact: That can lead to unintended file modification, privilege abuse, denial of service, audit confusion, or exposure of sensitive data through cleanup or log-handling mistakes.
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 | T1222 — File and Directory Permissions Modification | Hard link abuse often pairs with filesystem manipulation and privileged file access paths. |
| Recommendation — Hunt for suspicious filesystem manipulation and constrain privileged file operations to trusted paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Privileged file operations depend on tightly governed accounts and permissions that attackers try to abuse. |
| Recommendation — Restrict privileged filesystem actions to approved accounts and remove unnecessary access paths. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege limits the damage when file operations can be redirected through hard links. |
| SI-10 — Information Input Validation | Path and object validation failures are central to file-system abuse via hard links. | |
| Recommendation — Apply least privilege to file-processing services and administrative tooling that touch sensitive paths. Validate file inputs and object state before acting on paths that can be attacker-influenced. | ||
Practitioner Guidance
What to watch for: Review any code or tooling that deletes, rotates, archives, truncates, or reopens files after an earlier safety check. Those are the places where a hard link relationship is most likely to turn a harmless-looking name into a security problem.
Governance implication: Treat file-system safety as an ownership issue for platform, application, and operations teams together. The fix is rarely one control in isolation, it is a set of secure coding, deployment, and permission decisions that prevent name-based assumptions from crossing trust boundaries.
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 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org