PATH Hijacking is an attack where a user or process runs a malicious executable because the shell searches an attacker-controlled directory before the intended binary. It commonly exploits weak permissions, unsafe scripts, or inherited environment variables. Defenders should use absolute paths, constrain PATH, and avoid writable directories in command lookup.
What PATH hijacking means in practice
PATH hijacking is dangerous because command resolution trusts search order, not intent. If a writable directory appears before the legitimate binary, a shell, script, or service may launch the attacker’s program instead of the expected one.
The issue is not limited to interactive terminals. It also affects automation, startup scripts, scheduled tasks, and service wrappers that inherit environment variables or rely on relative commands. That makes the weakness a boundary problem between execution logic and filesystem trust.
Why search order becomes an execution control
The PATH variable is a convenience feature, but it becomes a control point whenever execution depends on it. A malicious executable named like a trusted command can win resolution if the process looks in an attacker-controlled location first, or if a directory earlier in PATH is not tightly protected.
This is why weak permissions, unsafe script patterns, and inherited environment settings matter. A vulnerable lookup path can silently redirect execution without changing the script content itself, which makes the attack easy to miss during review.
Common ways the attack succeeds
PATH hijacking often appears alongside broader execution-flow abuse. A weakly configured script may call tools by name only, a parent process may pass a polluted environment, or a user-writable directory may be inserted into the search path. In Windows and Unix-like environments alike, the attacker only needs the victim to resolve a command through the wrong directory.
It is especially risky where the invoked command runs with elevated trust, because the malicious replacement inherits that context. In those cases the hijack is not just a fake binary launch, it is an opportunity to inherit the permissions, data access, or persistence mechanisms of the victim process.
How defenders reduce exposure
Defence starts with making command resolution explicit. Use absolute paths for sensitive commands, keep PATH narrow and predictable, and ensure directories that appear early in search order are not writable by untrusted users. Review scripts, wrappers, and automation for relative command calls that depend on ambient environment state.
For host-level hardening and persistence review, see Persistence Techniques Guide, which covers path interception, search order hijacking, and related execution-flow abuse patterns. On the detection side, monitor for unexpected binaries in lookup paths, suspicious environment inheritance, and command executions that resolve outside approved locations.
Risk and Threat Considerations
PATH hijacking is a practical privilege-abuse technique because it turns a trust shortcut into code execution. The main risk is silent substitution: the victim believes it is launching a legitimate utility, but the attacker’s binary is the one that actually runs.
Failure mechanism: A trusted process searches an attacker-influenced directory before the intended binary, so the wrong executable is selected and run with the victim’s context.
Impact: This can produce unauthorized execution, privilege abuse, credential exposure, persistence, or broader host compromise when the launched process has elevated access.
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 | T1574.008 — Hijack Execution Flow: Path Interception by PATH Environment Variable | Directly describes PATH-based command interception and execution hijacking. |
| T1574.009 — Hijack Execution Flow: Path Interception by Unquoted Search Path | Covers execution hijacking through unsafe path lookup and search order conditions. | |
| Recommendation — Map suspicious command resolution to T1574.008 and hunt for attacker-controlled directories in search paths. Inspect command launch paths for unsafe search order and harden scripts to use explicit absolute paths. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | PATH hardening and writable-directory removal are secure configuration actions for hosts and scripts. |
| Recommendation — Harden command lookup paths and remove writable directories from any execution context. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Restricting available execution paths and unnecessary search locations supports least functionality. |
| SI-4 — System Monitoring | Monitoring unexpected binary resolution and execution supports detection of PATH hijacking. | |
| Recommendation — Limit execution paths to only the directories required for legitimate operations. Alert on unexpected executable resolution and investigate commands that run from unusual directories. | ||
Practitioner Guidance
Why practitioners should care: PATH hijacking is often introduced by convenience, not intent, which means it can persist in scripts and automation long after the original developer has moved on. The safest assumption is that any command resolution based on ambient PATH is a potential trust decision.
What to watch for: Look for writable directories in lookup paths, scripts that invoke tools without full paths, and services or scheduled jobs that inherit user-controlled environment variables. Treat these as review triggers, especially where the command runs with higher privilege than the caller.