CWE-427 Base Borrador

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…

Definición

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.
Impacto en el mundo real

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.

Cómo lo explotan los atacantes

Ruta del atacante paso a paso

  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.

Ejemplo de código vulnerable

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");
  ...
Ejemplo de código seguro

Secure pseudo

Seguro 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.
Lista de prevención

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.
Señales de detección

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

Auto-corrección de Plexicus

Plexicus detecta automáticamente CWE-427 y abre un PR de corrección en menos de 60 segundos.

Codex Remedium escanea cada commit, identifica esta debilidad concreta y entrega un pull request listo para revisión con el parche. Sin tickets. Sin traspasos.

Solicitar demo Probar Plexicus gratis
Preguntas frecuentes

Frequently asked questions

¿Qué es 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.

¿Qué gravedad tiene CWE-427?

MITRE no ha publicado una calificación de probabilidad de explotación para esta debilidad. Trátala como de impacto medio hasta que tu modelo de amenazas demuestre lo contrario.

¿Qué lenguajes o plataformas se ven afectados por CWE-427?

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

¿Cómo puedo prevenir 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…

¿Cómo detecta y corrige Plexicus CWE-427?

El motor SAST de Plexicus detecta la firma de flujo de datos para CWE-427 en cada commit. Cuando hay coincidencia, nuestro agente Codex Remedium abre un PR de corrección con el código corregido, las pruebas y un resumen de una línea para el revisor.

¿Dónde puedo aprender más sobre CWE-427?

MITRE publica la definición canónica en https://cwe.mitre.org/data/definitions/427.html. También puedes consultar la documentación de OWASP y NIST para guías relacionadas.

Debilidades relacionadas

Weaknesses related to CWE-427

CWE-668 Padre

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 Hermano

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 Hermano

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 Hermano

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 Hermano

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 Hermano

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 Hermano

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 Hermano

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 Hermano

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…

Recursos

Further reading

Listo cuando tú lo estés

Deja de pagar por desarrollador.
Empieza a cerrar el bucle.

Plexicus es el ASPM nativo de IA que escanea, filtra, corrige, pentestea y explica — de forma autónoma. Desarrolladores ilimitados, repos ilimitados, acciones de IA de uso justo. Nivel gratuito real, €269/mo anual cuando estés listo.

Comenzar gratis Reservar una demo