Skip to content

CWE-426: Untrusted Search Path

Overview

Untrusted Search Path occurs when an application searches for resources (e.g., executables, libraries) in directories that can be controlled by attackers, allowing them to inject malicious files that are loaded by the application.

OWASP Classification

A08:2025 - Software or Data Integrity Failures

Risk

High: Attackers can execute arbitrary code, escalate privileges, or compromise the system by placing malicious files in untrusted directories.

Remediation Steps

Core principle: Do not search/load code from untrusted locations; restrict search paths and verify component integrity.

Locate the untrusted search path vulnerability

  • Review the flaw details to identify where resources are loaded from untrusted search paths
  • Identify what's being loaded: executables, libraries, DLLs, shared objects, configuration files
  • Check how resource is located: relative path, PATH environment variable, LD_LIBRARY_PATH, system search order
  • Determine the risk: can attacker control directories in search path

Specify full paths for executables and libraries (Primary Defense)

  • Always use absolute paths: Use /usr/local/bin/mytool instead of mytool
  • Don't rely on PATH variable: Explicitly specify full path to avoid search path hijacking
  • Hard-code trusted paths: /usr/bin/python3, /opt/app/bin/script, C:\\Program Files\\App\\tool.exe
  • Validate executable location: Before execution, verify file exists at expected absolute path
  • Use getcwd() for relative paths: If relative paths needed, combine with current working directory explicitly

Restrict writable directories in search path

  • Ensure only trusted users can write: Directories in PATH should have restrictive permissions (755 or 700)
  • Remove untrusted directories: Remove ., ./, world-writable directories from PATH
  • Check directory permissions: Verify search path directories aren't writable by non-admin users
  • Avoid user home directories in PATH: Don't search ~/.local/bin or user-controlled paths for system services

Use safe loading functions and mechanisms

  • Use APIs with trusted directories: dlopen() with RTLD_NOLOAD, Windows LoadLibraryEx with LOAD_LIBRARY_SEARCH_SYSTEM32
  • Avoid deprecated loading: Don't use system(), popen() with relative paths
  • Pin library versions: Use specific library paths, not system search
  • Disable ./ search: Configure application to not search current directory first

Monitor and audit resource loading

  • Log all resource loading events (executable launches, library loads, file accesses)
  • Alert on unexpected or suspicious file loads (loads from temp directories, user-writable locations)
  • Track search path configuration changes
  • Monitor for DLL hijacking attempts (Windows)
  • Audit file system permissions on search path directories

Test the search path fix thoroughly

  • Test application loads resources from trusted absolute paths only
  • Test placing malicious file in current directory doesn't get executed
  • Test with modified PATH environment variable
  • Verify file permissions on search path directories
  • Test on different operating systems (Windows, Linux, macOS)
  • Re-scan with security scanner to confirm the issue is resolved

Common Vulnerable Patterns

  • Loading executables or libraries by name only
  • Including world-writable directories in the search path

Relative Executable Path Resolution (Pseudocode)

# Loads executable from untrusted search path
os.system('mytool')

Why this is vulnerable: Loading executables by name without absolute paths allows attackers to place malicious executables with the same name in directories earlier in the PATH (like current directory .), causing the application to execute attacker-controlled code instead of the intended binary, leading to privilege escalation or remote code execution.

Secure Patterns

Absolute Path for Executable (Pseudocode)

# Loads executable from trusted directory using absolute path
os.system('/usr/local/bin/mytool')
# or validate and sanitize PATH first
import subprocess
subprocess.run(['/usr/local/bin/mytool'], env={'PATH': '/usr/local/bin:/usr/bin'})

Why this works:

  • Uses absolute paths to eliminate search path ambiguity and prevent trojan binary execution
  • Prevents attackers from placing malicious executables named 'mytool' in user-writable directories
  • Blocks DLL hijacking, binary planting, and search order hijacking attacks
  • Ensures only the intended trusted executable is invoked, not attacker-controlled versions
  • Setting explicit PATH in subprocess prevents inheriting potentially malicious search paths

Additional Resources