An untrusted search path is a flaw where a program looks for a library or executable in locations an attacker can influence, then runs what it finds. It is catalogued as CWE-426. The fix is to load code from fixed, trusted locations by full path.
A definition with an example
Microsoft's Win32 documentation describes the classic case. When an application loads a DLL without a fully qualified path, Windows searches a defined set of directories in order. If an attacker controls one of those directories, they can place a malicious copy there. Microsoft calls this a DLL preloading attack or binary planting attack. If the application runs with administrator privileges, the attacker may gain local privilege elevation.
With safe DLL search mode on, the documented order is:
- The directory the application loaded from
- The system directory
- The 16 bit system directory
- The Windows directory
- The current directory
- Directories in the PATH variable
The current directory is the dangerous one. Anything that changes where the program starts, such as double clicking a file in a folder an attacker prepared, can change what gets loaded.
Why games and installers are exposed
Games and installers launch from downloads folders, from custom URI handlers and from launchers, and they ship many native libraries. Unity classified its CVE-2025-59489 advisory as CWE-426, so this is not a theoretical category for the game industry. The advisory notes a registered custom URI handler on Windows may raise exploitation risk.
What developers change
Microsoft's guidance includes:
- Specify a fully qualified path with LoadLibrary, LoadLibraryEx, CreateProcess and ShellExecute where possible.
- Use the LOAD_LIBRARY_SEARCH flags or SetDefaultDllDirectories to set a safe search order.
- Consider removing the current directory from the search path with SetDllDirectory using an empty string, early in process start, and test carefully if you load third party DLLs.
- Keep safe DLL search mode enabled.
- Do not use SearchPath to find a DLL for a later LoadLibrary call unless safe process search mode is enabled.
A review prompt for your own code
Search your codebase for every call that loads a library or starts a process by bare name. Each one is a question: could an attacker control the place it looks? Native plugins and middleware count too, so include them in the review.
Try it yourself
Static analysis can flag risky calls in code. Open the demo and notice how findings are grouped and explained.
Click through it at your own pace, or open it full screen.
Quick check
Is this a Windows only problem?
The Microsoft page is about Windows. The general class, loading code from an attacker influenced location, is not limited to one operating system. Unity's advisory lists several platforms.
Does code signing prevent it?
Not by itself. Signing checks the file you ship, but a planted DLL is a different file loaded at run time.
Safeguard's code and dependency scanning can surface risky patterns and vulnerable libraries in a build. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
