Uncontrolled Search Path Element

Draft Base
Structure: Simple
Description

This vulnerability occurs when an application searches for critical files like libraries or executables using a predefined list of directories, but one or more of those directories can be manipulated by an unauthorized user.

Extended Description

This issue most commonly surfaces when an application relies on a search path to locate dynamic libraries (DLLs) or executables without fully qualifying their location. On Windows, functions like LoadLibrary may check the application's load directory or the current working directory first, which an attacker can control. Similarly, on Unix-like systems, an improperly configured PATH variable—especially one containing an empty element representing the current directory—can redirect the application to load malicious code. Even network shares (like SMB) can become remote attack vectors if they are included in this untrusted search path. Beyond local file systems, the same principle applies to software dependency managers (npm, PyPI, RubyGems). These tools often search public package repositories before private ones. An attacker can exploit this order by uploading a malicious package with a name identical to a trusted internal package in the public repository. The core problem remains the same: the search sequence includes an element—be it a directory or a repository—that is not securely controlled, allowing for code substitution and compromise.

Common Consequences 1
Scope: ConfidentialityIntegrityAvailability

Impact: Execute Unauthorized Code or Commands

Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 5
Phase: Architecture and DesignImplementation

Strategy: Attack Surface Reduction

Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party. Be careful to avoid related weaknesses such as Untrusted Search Path and Unquoted Search Path or Element.
Phase: Implementation

Strategy: Attack Surface Reduction

When invoking other programs, specify those programs using fully-qualified pathnames. While this is an effective approach, code that uses fully-qualified pathnames might not be portable to other systems that do not use the same pathnames. The portability can be improved by locating the full-qualified paths in a centralized, easily-modifiable location within the source code, and having the code refer to these paths.
Phase: Implementation

Strategy: Attack Surface Reduction

Remove or restrict all environment settings before invoking other programs. This includes the PATH environment variable, LD_LIBRARY_PATH, and other settings that identify the location of code libraries, and any application-specific search paths.
Phase: Implementation
Check your search path before use and remove any elements that are likely to be unsafe, such as the current working directory or a temporary files directory. Since this is a denylist approach, it might not be a complete solution.
Phase: Implementation
Use other functions that require explicit paths. Making use of any of the other readily available functions that require explicit paths is a safe way to avoid this problem. For example, system() in C does not require a full path since the shell can take care of finding the program using the PATH environment variable, while execl() and execv() require a full path.
Demonstrative Examples 3

ID : DX-29

The following code is from a web application that allows users access to an interface through which they can update their password on the system. In this environment, user passwords can be managed using the Network Information System (NIS), which is commonly used on UNIX systems. When performing NIS updates, part of the process for updating passwords is to run a make command in the /var/yp directory. Performing NIS updates requires extra privileges.

Code Example:

Bad
Java
java
The problem here is that the program does not specify an absolute path for make and does not clean its environment prior to executing the call to Runtime.exec(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
In versions of Go prior to v1.19, the LookPath function would follow the conventions of the runtime OS and look for a program in the directiories listed in the current path [REF-1325].
Therefore, Go would prioritize searching the current directory when the provided command name does not contain a directory separator and continued to search for programs even when the specified program name is empty.
Consider the following where an application executes a git command to run on the system.

Code Example:

Bad
Go
go
An attacker could create a malicious repository with a file named ..exe and another file named git.exe. If git.exe is not found in the system PATH, then ..exe would execute [REF-1326].
In February 2021 [REF-1169], a researcher was able to demonstrate the ability to breach major technology companies by using "dependency confusion" where the companies would download and execute untrusted packages.
The researcher discovered the names of some internal, private packages by looking at dependency lists in public source code, such as package.json. The researcher then created new, untrusted packages with the same name as the internal packages, then uploaded them to package hosting services. These services included the npm registry for Node, PyPi for Python, and RubyGems. In affected companies, their dependency resolution would search the public hosting services first before consulting their internal service, causing the untrusted packages to be automatically downloaded and executed.
Observed Examples 30
CVE-2023-25815chain: a change in an underlying package causes the gettext function to use implicit initialization with a hard-coded path (Incorrect Initialization of Resource) under the user-writable C:\ drive, introducing an untrusted search path element (Uncontrolled Search Path Element) that enables spoofing of messages.
CVE-2022-4826Go-based git extension on Windows can search for and execute a malicious "..exe" in a repository because Go searches the current working directory if git.exe is not found in the PATH
CVE-2020-26284A Static Site Generator built in Go, when running on Windows, searches the current working directory for a command, possibly allowing code execution using a malicious .exe or .bat file with the name being searched
CVE-2022-24765Windows-based fork of git creates a ".git" folder in the C: drive, allowing local attackers to create a .git folder with a malicious config file
CVE-2019-1552SSL package searches under "C:/usr/local" for configuration files and other critical data, but C:/usr/local might be world-writable.
CVE-2010-3402"DLL hijacking" issue in document editor.
CVE-2010-3397"DLL hijacking" issue in encryption software.
CVE-2010-3138"DLL hijacking" issue in library used by multiple media players.
CVE-2010-3152"DLL hijacking" issue in illustration program.
CVE-2010-3147"DLL hijacking" issue in address book.
CVE-2010-3135"DLL hijacking" issue in network monitoring software.
CVE-2010-3131"DLL hijacking" issue in web browser.
CVE-2010-1795"DLL hijacking" issue in music player/organizer.
CVE-2002-1576Product uses the current working directory to find and execute a program, which allows local users to gain privileges by creating a symlink that points to a malicious version of the program.
CVE-1999-1461Product trusts the PATH environmental variable to find and execute a program, which allows local users to obtain root access by modifying the PATH to point to a malicous version of that program.
CVE-1999-1318Software uses a search path that includes the current working directory (.), which allows local users to gain privileges via malicious programs.
CVE-2003-0579Admin software trusts the user-supplied -uv.install command line option to find and execute the uv.install program, which allows local users to gain privileges by providing a pathname that is under control of the user.
CVE-2000-0854When a document is opened, the directory of that document is first used to locate DLLs , which could allow an attacker to execute arbitrary commands by inserting malicious DLLs into the same directory as the document.
CVE-2001-0943Database trusts the PATH environment variable to find and execute programs, which allows local users to modify the PATH to point to malicious programs.
CVE-2001-0942Database uses an environment variable to find and execute a program, which allows local users to execute arbitrary programs by changing the environment variable.
CVE-2001-0507Server uses relative paths to find system files that will run in-process, which allows local users to gain privileges via a malicious file.
CVE-2002-2017Product allows local users to execute arbitrary code by setting an environment variable to reference a malicious program.
CVE-1999-0690Product includes the current directory in root's PATH variable.
CVE-2001-0912Error during packaging causes product to include a hard-coded, non-standard directory in search path.
CVE-2001-0289Product searches current working directory for configuration file.
CVE-2005-1705Product searches current working directory for configuration file.
CVE-2005-1307Product executable other program from current working directory.
CVE-2002-2040Untrusted path.
CVE-2005-2072Modification of trusted environment variable leads to untrusted path vulnerability.
CVE-2005-1632Product searches /tmp for modules before other paths.
References 14
Double clicking on MS Office documents from Windows Explorer may execute arbitrary programs in some cases
Georgi Guninski
Bugtraq
18-09-2000
ID: REF-409
ACROS Security: Remote Binary Planting in Apple iTunes for Windows (ASPR #2010-08-18-1)
Mitja Kolsek
Bugtraq
18-08-2010
ID: REF-410
Automatic Detection of Vulnerable Dynamic Component Loadings
Taeho Kwon and Zhendong Su
ID: REF-411
Dynamic-Link Library Search Order
Microsoft
02-09-2010
ID: REF-412
Dynamic-Link Library Security
Microsoft
02-09-2010
ID: REF-413
An update on the DLL-preloading remote attack vector
Microsoft
31-08-2010
ID: REF-414
Insecure Library Loading Could Allow Remote Code Execution
Microsoft
23-08-2010
ID: REF-415
Application DLL Load Hijacking
HD Moore
23-08-2010
ID: REF-416
DLL Hijacking: Facts and Fiction
Oliver Lavery
26-08-2010
ID: REF-417
Microsoft warns enterprises of new 'dependency confusion' attack technique
Catalin Cimpanu
ZDNet
10-02-2021
ID: REF-1168
Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies
Alex Birsan
09-02-2021
ID: REF-1169
exec package - os/exec - Go Packages
04-04-2023
ID: REF-1325
Git LFS Changelog
Brian M. Carlson
19-04-2022
ID: REF-1326
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Implementation
Alternate Terms

DLL preloading

This term is one of several that are used to describe exploitation of untrusted search path elements in Windows systems, which received wide attention in August 2010. From a weakness perspective, the term is imprecise because it can apply to both Untrusted Search Path and Uncontrolled Search Path Element.

Binary planting

This term is one of several that are used to describe exploitation of untrusted search path elements in Windows systems, which received wide attention in August 2010. From a weakness perspective, the term is imprecise because it can apply to both Untrusted Search Path and Uncontrolled Search Path Element.

Insecure library loading

This term is one of several that are used to describe exploitation of untrusted search path elements in Windows systems, which received wide attention in August 2010. From a weakness perspective, the term is imprecise because it can apply to both Untrusted Search Path and Uncontrolled Search Path Element.

Dependency confusion

As of February 2021, this term is used to describe Uncontrolled Search Path Element in the context of managing installation of software package dependencies, in which attackers release packages on public sites where the names are the same as package names used by private repositories, and the search for the dependent package tries the public site first, downloading untrusted code. It may also be referred to as a "substitution attack."
Functional Areas
  1. Program Invocation
  2. Code Libraries
Affected Resources
  1. System Process
Taxonomy Mapping
  • PLOVER
Notes
RelationshipUnlike untrusted search path (Untrusted Search Path), which inherently involves control over the definition of a control sphere (i.e., modification of a search path), this entry concerns a fixed control sphere in which some part of the sphere may be under attacker control (i.e., the search path cannot be modified by an attacker, but one element of the path can be under attacker control).
TheoreticalThis weakness is not a clean fit under Exposure of Resource to Wrong Sphere or Externally Controlled Reference to a Resource in Another Sphere, which suggests that the control sphere model might need enhancement or clarification.