CWE-427 Base Draft

Uncontrolled Search Path Element

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…

Definition

What is CWE-427?

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.
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.
Real-world impact

Real-world CVEs caused by CWE-427

  • CVE-2023-25815

    chain: a change in an underlying package causes the gettext function to use implicit initialization with a hard-coded path (CWE-1419) under the user-writable C:\ drive, introducing an untrusted search path element (CWE-427) that enables spoofing of messages.

  • CVE-2022-4826

    Go-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-26284

    A 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-24765

    Windows-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-1552

    SSL 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.

How attackers exploit it

Step-by-step attacker path

  1. 1

    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.

  2. 2

    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.

  3. 3

    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].

  4. 4

    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.

  5. 5

    Consider the following where an application executes a git command to run on the system.

Vulnerable code example

Vulnerable Java

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.

Vulnerable Java 
...
  System.Runtime.getRuntime().exec("make");
  ...
Secure code example

Secure pseudo

Secure pseudo 
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
  const safe = validateAndEscape(input);
  return executeWithGuards(safe);
}
What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist

How to prevent CWE-427

  • Architecture and Design / Implementation 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 CWE-426 and CWE-428.
  • Implementation 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.
  • Implementation 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.
  • 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.
  • 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.
Detection signals

How to detect CWE-427

Automated Static Analysis High

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.)

Plexicus auto-fix

Plexicus auto-detects CWE-427 and opens a fix PR in under 60 seconds.

Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.

Get a demo Try Plexicus free
Frequently asked questions

Frequently asked questions

What is CWE-427?

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.

How serious is CWE-427?

MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.

What languages or platforms are affected by CWE-427?

MITRE lists the following affected platforms: Not OS-Specific.

How can I prevent CWE-427?

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 CWE-426 and CWE-428. 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…

How does Plexicus detect and fix CWE-427?

Plexicus's SAST engine matches the data-flow signature for CWE-427 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.

Where can I learn more about CWE-427?

MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/427.html. You can also reference OWASP and NIST documentation for adjacent guidance.

Related weaknesses

Weaknesses related to CWE-427

CWE-668 Parent

Exposure of Resource to Wrong Sphere

This vulnerability occurs when an application unintentionally makes a resource accessible to users or systems that should not have…

CWE-1189 Sibling

Improper Isolation of Shared Resources on System-on-a-Chip (SoC)

This vulnerability occurs when a System-on-a-Chip (SoC) fails to properly separate shared hardware resources between secure (trusted) and…

CWE-1282 Sibling

Assumed-Immutable Data is Stored in Writable Memory

This vulnerability occurs when data that should be permanent and unchangeable—like a bootloader, device IDs, or one-time configuration…

CWE-1327 Sibling

Binding to an Unrestricted IP Address

This vulnerability occurs when software or a service is configured to bind to the IP address 0.0.0.0 (or :: in IPv6), which acts as a…

CWE-1331 Sibling

Improper Isolation of Shared Resources in Network On Chip (NoC)

This vulnerability occurs when a Network on Chip (NoC) fails to properly separate its internal, shared resources—like buffers, switches,…

CWE-134 Sibling

Use of Externally-Controlled Format String

This vulnerability occurs when a program uses a format string from an untrusted, external source (like user input, a network packet, or a…

CWE-200 Sibling

Exposure of Sensitive Information to an Unauthorized Actor

This weakness occurs when an application unintentionally reveals sensitive data to someone who shouldn't have access to it.

CWE-374 Sibling

Passing Mutable Objects to an Untrusted Method

This vulnerability occurs when a function receives a direct reference to mutable data, such as an object or array, instead of a safe copy…

CWE-375 Sibling

Returning a Mutable Object to an Untrusted Caller

This vulnerability occurs when a method directly returns a reference to its internal mutable data, allowing untrusted calling code to…

Resources

Further reading

Ready when you are

Don't Let Security
Weigh You Down.

Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.

Get started free Book a demo