What CVEs are caused by CWE-426?

257 recorded CVEs are attributed to CWE-426, including CVE-2022-22047, CVE-2012-1854, CVE-2025-26155. 2 are listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.

Is CWE-426 actively exploited?

Yes. 2 CWE-426 vulnerabilities are in CISA's KEV catalog of actively exploited flaws, out of 257 recorded CVEs.

Base weakness

Stable

CWE-426: Untrusted Search Path

Also known as: Untrusted Path

The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.

Last updated May 1, 2026

257

Recorded CVEs

With this primary weakness

KEVs

In the CISA KEV catalog

High

Likelihood of exploit

Per MITRE

Base

Abstraction

MITRE classification

Overview

This might allow attackers to execute their own programs, access unauthorized data files, or modify configuration in unexpected ways. If the product uses a search path to locate critical resources such as programs, then an attacker could modify that search path to point to a malicious program, which the targeted product would then execute. The problem extends to any type of critical resource that the product trusts. Some of the most common variants of untrusted search path are: In various UNIX and Linux-based systems, the PATH environment variable may be consulted to locate executable programs, and LD_PRELOAD may be used to locate a separate library. In various Microsoft-based systems, the PATH environment variable is consulted to locate a DLL, if the DLL is not found in other paths that appear earlier in the search order.

Real-world CVEs

257 recorded CVEs are caused by CWE-426 (Untrusted Search Path), including 2 in CISA's KEV (Known Exploited Vulnerabilities) catalog. KEVs are shown first. 58 new CWE-426 CVEs have been recorded so far in 2026 (57 in 2025).

Showing 12 of 257 recorded CWE-426 CVEs. Track new ones as they are published and get AI-written analysis and fixes.

Monitor CWE-426 vulnerabilities

Common consequences

What can happen when CWE-426 is exploited.

Gain Privileges or Assume Identity, Execute Unauthorized Code or Commands

Affects: Integrity, Confidentiality, Availability, Access Control

There is the potential for arbitrary code execution with privileges of the vulnerable program.

DoS: Crash, Exit, or Restart

Affects: Availability

The program could be redirected to the wrong files, potentially triggering a crash or hang when the targeted file is too large or does not have the expected format.

Read Files or Directories

Affects: Confidentiality

The program could send the output of unauthorized files to the attacker.

How it happens

When it is introduced

Typically introduced during these phases of the software lifecycle.

Implementation

How to prevent it

Practical mitigations for CWE-426, grouped by where in the lifecycle they apply.

Architecture and Design

Implementation

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

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 it, while execl() and execv() require a full path.

How to detect it

Black Box

Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process and look for library functions and system calls that suggest when a search path is being used. One pattern is when the program performs multiple accesses of the same file but in different directories, with repeated failures until the proper filename is found. Library calls such as getenv() or their equivalent can be checked to see if any path-related variables are being accessed.

Automated Static Analysis

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

Effectiveness: High

Manual Analysis

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Code examples

Illustrative examples from MITRE showing how the weakness appears in code.

This program is intended to execute a command that lists the contents of a restricted directory, then performs other actions. Assume that it runs with setuid privileges in order to bypass the permissions check by the operating system.

Vulnerable example

/* Raise privileges to those needed for accessing DIR. */
#define DIR "/restricted/directory"

The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.

The code above allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

This code prints all of the running processes belonging to the current user.

Vulnerable example

php

//assume getCurrentUser() returns a username that is guaranteed to be alphanumeric (avoiding CWE-78)

If invoked by an unauthorized web user, it is providing a web page of potentially sensitive information on the underlying system, such as command-line arguments (CWE-497). This program is also potentially vulnerable to a PATH based attack (CWE-426), as an attacker may be able to create malicious versions of the ps or grep commands. While the program does not explicitly raise privileges to run the system commands, the PHP interpreter may by default be running with higher privileges than users.

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.

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.

Illustrative examples

Real CVEs that MITRE cites as examples of this weakness.

CVE-1999-1120 — Application relies on its PATH environment variable to find and execute program.
CVE-2008-1810 — Database application relies on its PATH environment variable to find and execute program.
CVE-2007-2027 — Chain: untrusted search path enabling resultant format string by loading malicious internationalization messages.
CVE-2008-3485 — Untrusted search path using malicious .EXE in Windows environment.
CVE-2008-2613 — setuid program allows compromise using path that finds and loads a malicious library.
CVE-2008-1319 — Server allows client to specify the search path, which can be modified to point to a program that the client has uploaded.

Terminology & mappings

Alternate terms

Untrusted Path

Mapped taxonomies

PLOVER: Untrusted Search Path
CLASP: Relative path library search
CERT C Secure Coding: Sanitize the environment when invoking external programs (ENV03-C)

Attack patterns

CAPEC attack patterns that exploit this weakness.

CAPEC-38: Leveraging/Manipulating Configuration File Search Paths

Frequently asked questions

Common questions about CWE-426.

What is CWE-426?: The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.
What CVEs are caused by CWE-426?: 257 recorded CVEs are attributed to CWE-426, including CVE-2022-22047, CVE-2012-1854, CVE-2025-26155. 2 are listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.
How do you prevent CWE-426?: 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.
How is CWE-426 detected?: Black Box: Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.
What are the consequences of CWE-426?: Exploiting CWE-426 can lead to: Gain Privileges or Assume Identity, Execute Unauthorized Code or Commands, DoS: Crash, Exit, or Restart, Read Files or Directories.
Is CWE-426 actively exploited?: Yes. 2 CWE-426 vulnerabilities are in CISA's KEV catalog of actively exploited flaws, out of 257 recorded CVEs.

References

Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.

Stay ahead of CWE-426

Get alerted the moment a new CWE-426 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.

Start free See pricing

Overview

Real-world CVEs

Common consequences

How it happens

When it is introduced

How to prevent it

How to detect it

Black Box

Automated Static Analysis

Manual Analysis

Code examples

Illustrative examples

Related weaknesses

Parent

Peer

Related

Terminology & mappings

Alternate terms

Mapped taxonomies

Attack patterns

Frequently asked questions

References

Stay ahead of CWE-426