cve.bz

CAPEC-471

Search Order Hijacking

Medium severityDetailed pattern

An adversary exploits a weakness in an application's specification of external libraries to exploit the functionality of the loader where the process loading the library searches first in the same directory in which the process binary resides and then in other directories. Exploitation of this preferential search order can allow an attacker to make the loading process load the adversary's rogue library rather than the legitimate library. This attack can be leveraged with many different libraries and with many different loading processes. No forensic trails are left in the system's registry or file system that an incorrect library had been loaded.

On this page

Ask an AI about this attack pattern

ChatGPTClaudeGoogle AI Mode

Show the promptExplain the attack pattern CAPEC-471: Search Order Hijacking: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/471.html and https://cve.bz/cve/capec/471?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.

Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.

How the attack unfolds

  1. Explore

    The attacker looks for a way in.

    1. [Identify target general susceptibility] An attacker uses an automated tool or manually finds whether the target application uses dynamically linked libraries and the configuration file or look up table (such as Procedure Linkage Table) which contains the entries for dynamically linked libraries.

      2 techniques
      • The attacker uses a tool such as the OSX "otool" utility or manually probes whether the target application uses dynamically linked libraries.
      • The attacker finds the configuration files containing the entries to the dynamically linked libraries and modifies the entries to point to the malicious libraries the attacker crafted.

  2. Experiment

    They probe what they found.

    1. [Craft malicious libraries] The attacker uses knowledge gained in the Explore phase to craft malicious libraries that they will redirect the target to leverage. These malicious libraries could have the same APIs as the legitimate library and additional malicious code.

      1 technique
      • The attacker monitors the file operations performed by the target application using a tool like dtrace or FileMon. And the attacker can delay the operations by using "sleep(2)" and "usleep()" to prepare the appropriate conditions for the attack, or make the application perform expansive tasks (large files parsing, etc.) depending on the purpose of the application.

  3. Exploit

    They carry out the attack.

    1. [Redirect the access to libraries to the malicious libraries] The attacker redirects the target to the malicious libraries they crafted in the Experiment phase. The attacker will be able to force the targeted application to execute arbitrary code when the application attempts to access the legitimate libraries.

      3 techniques
      • The attacker modifies the entries in the configuration files pointing to the malicious libraries they crafted.
      • The attacker leverages symlink/timing issues to redirect the target to access the malicious libraries they crafted. See also: CAPEC-132.
      • The attacker leverages file search path order issues to redirect the target to access the malicious libraries they crafted. See also: CAPEC-38.

Prerequisites

  • Attacker has a mechanism to place its malicious libraries in the needed location on the file system.

Skills required

  • Medium skill

    Ability to create a malicious library.

Mitigations

  • Design: Fix the Windows loading process to eliminate the preferential search order by looking for DLLs in the precise location where they are expected

  • Design: Sign system DLLs so that unauthorized DLLs can be detected.

Weaknesses it exploits

  • CWE-427 Uncontrolled Search Path Element

Recent CVEs with these weaknesses

  1. 5.4CVE-2026-20798

    Uncontrolled search path for some Intel(R) Graphics Driver software installers within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with an authenticated user combined with a high complexit…

  2. 6.7CVE-2026-9063

    A locally authenticated user can achieve privilege escalation via an insecure configuration that leads to unauthorized code execution. This flaw can only be exploited after authenticating with an admin-privileged service account.

  3. 8.2CVE-2026-86579

    Binary Planting Vulnerability in Hitachi Dynamic Link Manager for Windows. This issue affects Hitachi Dynamic Link Manager for Windows: from 5.9.5-00 before 9.0.4-01.

  4. 7.5CVE-2026-120015

    SAP Host Agent does not sufficiently validate certain inputs. Under certain condition, an attacker with low privileges could abuse the affected functionality to influence an internal component into loading a malicious file under a privileg…

  5. 7.8CVE-2026-114032

    The OpenSSL library bundled with the Illumio VEN for Windows is affected by an uncontrolled search path vulnerability. A low-privileged, authenticated local attacker could potentially leverage this vulnerability to execute arbitrary code w…

  6. 9.3CVE-2026-104989

    Uncontrolled search path element in package upload feature in Chaos Software V-Ray versions through 2.0.19 allows remote unauthenticated attackers to execute arbitrary code via redirecting access to libraries

  7. 6.3CVE-2026-112170

    The software downloads upgrade files without performing integrity checks, allowing the installation of tampered updates.

  8. 5.9CVE-2026-118450

    Venere is installed outside Program Files and loads/registers unsigned components from locations where an unprivileged user may create files.

The newest records naming one of them. Each weakness's page lists them all.

Part of

Examples

For instance, an attacker with access to the file system may place a malicious ntshrui.dll in the C:\Windows …

For instance, an attacker with access to the file system may place a malicious ntshrui.dll in the C:\Windows directory. This DLL normally resides in the System32 folder. Process explorer.exe which also resides in C:\Windows, upon trying to load the ntshrui.dll from the System32 folder will actually load the DLL supplied by the attacker simply because of the preferential search order. Since the attacker has placed its malicious ntshrui.dll in the same directory as the loading explorer.exe process, the DLL supplied by the attacker will be found first and thus loaded in lieu of the legitimate DLL. Since explorer.exe is loaded during the boot cycle, the attackers' malware is guaranteed to execute.

macOS and OS X use a common method to look for required dynamic libraries (dylib) to load into a program base…

macOS and OS X use a common method to look for required dynamic libraries (dylib) to load into a program based on search paths. Adversaries can take advantage of ambiguous paths to plant dylibs to gain privilege escalation or persistence. A common method is to see what dylibs an application uses, then plant a malicious version with the same name higher up in the search path. This typically results in the dylib being in the same folder as the application itself. If the program is configured to run at a higher privilege level than the current user, then when the dylib is loaded into the application, the dylib will also run at that elevated level.

MITRE's words, unchanged: CAPEC-471 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.