CWE-427 covers products that use a fixed or controlled search path to find resources, where one or more locations in that path can be controlled by unintended actors. It is a close cousin of CWE-426: there, the whole path comes from outside. Here, the path is yours, but one entry in it is not safe.
It affects anything that loads executables or libraries by name, and it shows up in desktop software, developer tools and package managers.
How it happens
MITRE describes frequent forms:
- A search path containing a directory an attacker can modify, such as
/tmpor the current working directory. - On Windows, calling
LoadLibraryorLoadLibraryExwith a DLL name that is not fully qualified. The search order includes the directory the program loaded from and the current working directory, both of which may be uncontrolled. Sometimes the attack works remotely through SMB or WebDAV shares. - The Windows drive root and some subdirectories, which have weak permissions by default.
- On some Unix systems, a PATH built with an empty element, for example by splicing in an empty variable. The empty element can mean the current directory.
- Software package managers such as npm, RubyGems and PyPI, where the framework identifies dependencies and may resolve them from a place an attacker can influence.
/* Vulnerable: bare DLL name, search order includes uncontrolled places */
HMODULE h = LoadLibraryW(L"helper.dll");
/* Safer: restrict to the system directory when appropriate */
HMODULE h2 = LoadLibraryExW(L"helper.dll", NULL, LOAD_LIBRARY_SEARCH_SYSTEM32);
MITRE's observed examples include several Go and Windows cases:
- A Go based git extension on Windows could 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-2022-4826).
- A Go static site generator on Windows searched the current working directory for a command, possibly allowing code execution through a malicious .exe or .bat file (CVE-2020-26284).
- A Windows fork of git created a ".git" folder on the C: drive, so local attackers could create one with a malicious config file (CVE-2022-24765).
- A chain where a package change made gettext use a hard coded path under the user writable C: drive (CVE-2023-25815).
What an attacker gains
The record lists execution of unauthorized code or commands, affecting confidentiality, integrity and availability. The code runs with the privileges of the program that loaded it.
How to find it
MITRE lists automated static analysis, which can find some instances by modeling data flow. Add these checks:
- Search for load and exec calls that use bare names.
- Audit PATH construction in scripts for empty elements and writable directories.
- Use a process monitor on a test machine to watch where a program looks for files and which of those locations a standard user can write to.
- Review how your build and package tooling resolves dependencies. Your dependency inventory is a good starting list, since a free scan in your browser covers up to 100 dependencies and your file stays local.
How to fix it
- Fully qualify paths for libraries and executables.
- Use restricted load flags on Windows so loads come from known directories only.
- Never include the current directory in a search path, and avoid empty PATH elements.
- Keep search directories write protected from standard users.
- Pin and verify dependencies in package managers.
Try it yourself
The demo shows how to build an inventory of the packages your project resolves, which is the first step in reviewing where code is loaded from.
Click through it at your own pace, or open it full screen.
Quick check
How is CWE-427 different from CWE-426?
In CWE-426 the search path itself comes from an outside source. In CWE-427 the path is fixed or controlled by the product, but one location in it can be written by others.
Why is the current directory dangerous?
A user may run your tool from a folder that contains attacker planted files, such as a downloaded repository.
