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.
Untrusted Search Path
This vulnerability occurs when an application relies on an external search path, provided by a user or environment, to find and load critical resources like executables or libraries. Because the…
What is CWE-426?
Real-world CVEs caused by CWE-426
-
Application relies on its PATH environment variable to find and execute program.
-
Database application relies on its PATH environment variable to find and execute program.
-
Chain: untrusted search path enabling resultant format string by loading malicious internationalization messages.
-
Untrusted search path using malicious .EXE in Windows environment.
-
setuid program allows compromise using path that finds and loads a malicious library.
-
Server allows client to specify the search path, which can be modified to point to a program that the client has uploaded.
Step-by-step attacker path
- 1
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.
- 2
This code may look harmless at first, since both the directory and the command are set to fixed values that the attacker can't control. The attacker can only see the contents for DIR, which is the intended program behavior. Finally, the programmer is also careful to limit the code that executes with raised privileges.
- 3
However, because the program does not modify the PATH environment variable, the following attack would work:
- 4
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.
- 5
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.
Vulnerable C
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.
#define DIR "/restricted/directory"
char cmd[500];
sprintf(cmd, "ls -l %480s", DIR);
```
/* Raise privileges to those needed for accessing DIR. */*
RaisePrivileges(...);
system(cmd);
DropPrivileges(...);
...However, because the program does not modify the PATH environment variable, the following attack would work:
- The user sets the PATH to reference a directory under the attacker's control, such as "/my/dir/".
- The attacker creates a malicious program called "ls", and puts that program in /my/dir
- The user executes the program.
- When system() is executed, the shell consults the PATH to find the ls program
- The program finds the attacker's malicious program, "/my/dir/ls". It doesn't find "/bin/ls" because PATH does not contain "/bin/".
- The program executes the attacker's malicious program with the raised privileges.Secure pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
const safe = validateAndEscape(input);
return executeWithGuards(safe);
}How to prevent CWE-426
- 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.
- 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 CWE-426
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.)
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.
Plexicus auto-detects CWE-426 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.
Frequently asked questions
What is CWE-426?
This vulnerability occurs when an application relies on an external search path, provided by a user or environment, to find and load critical resources like executables or libraries. Because the application does not fully control this path, an attacker can manipulate it to point to malicious files.
How serious is CWE-426?
MITRE rates the likelihood of exploit as High — this weakness is actively exploited in the wild and should be prioritized for remediation.
What languages or platforms are affected by CWE-426?
MITRE lists the following affected platforms: Not OS-Specific.
How can I 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. 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-426?
Plexicus's SAST engine matches the data-flow signature for CWE-426 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-426?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/426.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Weaknesses related to CWE-426
External Control of Critical State Data
This vulnerability occurs when an application stores security-sensitive state data in locations that unauthorized users can access and…
External Control of System or Configuration Setting
This vulnerability occurs when an application allows users to directly modify critical system settings or configuration values from an…
External Control of Assumed-Immutable Web Parameter
This vulnerability occurs when a web application incorrectly trusts data that appears to be fixed or hidden from the user, such as values…
Reliance on Cookies without Validation and Integrity Checking
This vulnerability occurs when an application uses cookies to make security decisions—like granting access or changing settings—but fails…
External Control of File Name or Path
This vulnerability occurs when an application uses unvalidated user input to construct file or directory paths for filesystem operations.
Uncontrolled Search Path Element
This vulnerability occurs when an application searches for critical files like libraries or executables using a predefined list of…
Unquoted Search Path or Element
This vulnerability occurs when a program uses a file path or command that contains spaces and is not enclosed in quotes. The operating…
Further reading
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.