Untrusted Search Path occurs when an application searches for executables, libraries, or other critical resources using a path that an attacker can influence…
Untrusted Search Path occurs when an application searches for executables, libraries, or other critical resources using a path that an attacker can influence or modify. Instead of loading the intended resource from a secure location, the application may load a malicious substitute placed earlier in the search path, leading to arbitrary code execution or privilege escalation.
Applications often rely on search paths (like PATH environment variables, working directories, or library load paths) to locate and load resources at runtime. If an attacker can control or predict these paths—by modifying environment variables, creating files in shared directories, or exploiting relative path resolution—they can place a malicious executable or library in a location the application will search before the legitimate one. The application then loads and executes the attacker's version instead, often with the privileges of the running process.
This is particularly dangerous when applications run with elevated privileges (such as setuid binaries on Unix systems or services running as SYSTEM on Windows) or when they load libraries dynamically without validating the source.
Successful exploitation can result in arbitrary code execution with the privileges of the vulnerable application. An attacker could gain unauthorized access to sensitive data, modify system files, escalate privileges from a regular user to administrator, or establish persistent backdoors. In multi-user or shared hosting environments, this can allow lateral movement between user accounts or compromise of the entire system.
import subprocess
import os
# Attacker can modify PATH environment variable
user_input = os.environ.get('PATH', '/usr/bin:/bin')
result = subprocess.run('some_tool', shell=True, env={'PATH': user_input})Why it's vulnerable:
The application trusts the PATH environment variable, which an attacker can modify to point to directories containing malicious executables with the same name as legitimate tools.
import subprocess
# Use absolute path to the executable
result = subprocess.run('/usr/bin/some_tool', shell=False)<?php
// Relative path allows attacker to place malicious library in current directory
$library_path = 'includes/helper.php';
require_once($library_path);
// Or relying on include_path set via environment
$file = 'config.php';
include($file);
?>Why it's vulnerable:
Relative paths and reliance on include_path allow an attacker to place a malicious file in a predictable location that gets loaded before the legitimate one.
<?php
// Use absolute path with __DIR__ constant
$library_path = __DIR__ . '/includes/helper.php';
require_once($library_path);
// Or use a hardcoded absolute path
$config_file = '/etc/app/config.php';
if (file_exists($config_file)) {
include($config_file);
}
?>PATH resolution.
/tmp, current working directory, and shared library directories) to prevent attackers from placing malicious files.
PATH, LD_LIBRARY_PATH, or similar variables from the calling environment.
Unexpected executables or libraries appearing in shared directories (like /tmp or the application's working directory), unusual process execution logs showing the application loading resources from unexpected paths, or reports of privilege escalation from unprivileged users. If your application runs with elevated privileges and users can influence its working directory or environment, this risk is elevated.
