TL;DR: DLL sideloading lets attackers load malicious code alongside a legitimate executable by exploiting Windows DLL search order behaviour, as Airlock Digital explains in its CPU-Z incident walkthrough. The core lesson is that allowlisting has to cover runtime-loaded components as well as the signed primary binary, because trust at launch does not guarantee trust at execution.
At a glance
What this is: DLL sideloading is a supply chain abuse technique where a legitimate Windows executable loads a malicious DLL at runtime instead of the intended library.
Why it matters: It matters because IAM and security teams need to govern what trusted software is allowed to load, not only what is allowed to start, especially in software distribution and build-chain contexts.
Context
DLL sideloading is a Windows loading behaviour issue, not a flaw in the application’s signed primary binary. The security gap appears when trust is granted at launch, but the runtime loader can still resolve a malicious library from a local directory before the intended system copy.
In supply chain abuse, that distinction matters because delivery, execution, and trust are not the same thing. For identity and access teams, the lesson extends beyond software integrity: runtime trust decisions need the same scrutiny as packaging and signing decisions, because trusted software can become the vehicle for untrusted code.
The CPU-Z case is typical of a broader class of supply chain abuse where attackers exploit normal software behaviour rather than breaking the application itself.
Key questions
Q: What fails when allowlisting only covers the primary executable in DLL sideloading scenarios?
A: The control fails because the allowed application can still load an attacker-controlled library at runtime. That leaves the launch decision protected but the execution path open, which is exactly how sideloading turns trusted software into a payload carrier. Effective control has to validate both the binary that starts and the modules it resolves, especially in Windows environments with permissive search order behaviour.
Q: Why does DLL sideloading remain effective in supply chain attacks?
A: It remains effective because it exploits normal Windows loader behaviour rather than obvious tampering with the main application. Security teams often trust the signed executable and miss the dependency chain beside it, so the malicious DLL inherits legitimacy from the allowed program. The risk is not the binary signature alone, but the runtime trust that signature can unintentionally extend.
Q: Where do application controls break down when software loads libraries at runtime?
A: They break down when policy stops at the first file that launches and does not separately govern the libraries, plugins, or helper components the process loads afterward. That creates a blind spot where the executable is approved but the code it pulls in is not. Teams should test whether their controls can distinguish initial execution from dependent code loading.
Q: Should security teams treat sideloaded DLLs as part of software provenance reviews?
A: Yes. If a supply chain review only covers the signed package or installer, it can miss the files that actually run at execution time. Teams should review adjacent runtime components, search paths, and deployment locations as part of provenance and endpoint control, because the attack often succeeds without altering the vendor’s primary binary.
Technical breakdown
Why Windows DLL search order creates a runtime trust gap
Windows applications may search the local application directory before system locations when loading a required DLL. If an attacker can place a file with the expected name beside a legitimate executable, the loader can bind to the malicious library during startup. The signed executable remains intact, which is why launch-time checks alone can miss the compromise. This is a runtime integrity problem, not a code-signing problem. The relevant control question is whether the environment can distinguish the trusted primary binary from the additional modules it loads.
Practical implication: validate runtime-loaded libraries, not only the signed executable that starts the process.
How sideloading turns trusted software into an execution path
DLL sideloading works because the attacker does not need to replace the application. They only need to influence which dependency is loaded when the process resolves its imports. That makes the technique attractive in supply chain attacks, where users, administrators, or security tools may trust the main program name and signature while overlooking the library search path. The real risk is delegated execution through normal operating system behaviour. In identity terms, this is a form of trust inheritance, where the permitted application inherits the attacker’s library choice at runtime.
Practical implication: treat library resolution as an access decision and restrict writable locations that can affect it.
Why allowlisting has to cover dependent code paths
Application control only works when policy applies to the full execution chain. If the primary executable is allowed but sideloaded DLLs are not separately governed, the control boundary ends too early and the malicious payload still runs. Deny by default approaches reduce that gap by requiring explicit trust for both the program and the code it loads. That is especially important in enterprise software distribution, where signed binaries may coexist with unsigned helper files, plugins, or runtime dependencies. The control objective is to collapse the trust gap between authorised launch and authorised execution.
Practical implication: extend application control policies to runtime dependencies, helper DLLs, and plugin directories.
Threat narrative
Attacker objective: The attacker aims to execute malicious code through a trusted application without modifying the main binary.
- Entry occurs when an attacker places a malicious DLL in the path a legitimate Windows application will search at runtime.
- Credential or trust abuse follows when the trusted executable loads the attacker-controlled library as part of normal startup.
- Impact occurs when malicious code executes under the legitimacy of the allowed application, bypassing the assumption that signing the primary binary is sufficient.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
DLL sideloading is a runtime trust problem, not just a software integrity problem. The CPU-Z case shows that a signed primary binary can remain legitimate while the executable path still becomes hostile through a malicious dependency. That shifts the security question from whether software is trusted at launch to whether every runtime load decision is governed. Practitioners should treat dynamic loading as part of the trust boundary, not an implementation detail.
Runtime-loaded components create a hidden supply chain layer. Traditional supply chain discussions often focus on source, build, and package integrity, but this technique shows that compromise can occur after distribution when the loader resolves adjacent files. That is a distinct governance gap because the software vendor may have done everything right for the main application while the environment still permits dependency hijacking. Practitioners should map this to the same discipline used for software provenance and execution control.
Allowlisting only the primary executable leaves a control-shaped hole. If policy does not separately evaluate libraries, plugins, and helper binaries, attackers can preserve the appearance of trusted execution while redirecting execution flow. This is the kind of failure mode that makes broad trust models brittle in enterprise Windows estates. Practitioners should align application control with the full execution chain, not a single file hash.
Supply chain abuse is increasingly about control gaps at the boundary between authorised and unauthorised code. The named concept here is runtime trust inheritance: a permitted executable inherits the attacker’s chosen dependency when policy stops at the first binary. That concept matters across software distribution, endpoint controls, and identity governance because trust decisions must remain valid after initial authorisation. Practitioners should audit where execution trust silently extends beyond the intended policy boundary.
For identity teams, the lesson is that trust must be continuously justified. A signed binary, an approved package, or an allowed process name does not guarantee the loaded code is still within policy. That is directly relevant to NHI governance where one trusted identity can execute many downstream actions. Practitioners should extend governance from identity approval to runtime authorisation.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Runtime trust inheritance: once policy approves a program, many environments implicitly trust whatever it loads next, which is why DLL sideloading remains a durable abuse pattern. That gap matters for endpoint hardening, software provenance, and any control that assumes a signed binary is the end of the decision. Practitioners should extend enforcement to the library layer, not just the launcher.
Supply chain security programmes should now treat dynamic loading paths as governed assets. When a local directory can outrank the intended system copy, the attack surface is no longer limited to distribution or installation. Practitioners should review writable paths, plugin directories, and application control exceptions as part of the same control family.
For practitioners
- Tighten application control around runtime dependencies Block unsigned or untrusted DLLs even when the parent executable is approved, so the loading decision is governed separately from the launch decision.
- Constrain writable search paths Remove user-writable directories from DLL search paths where possible and audit applications that load libraries from the local directory before system locations.
- Inventory applications that rely on dynamic loading Identify software that uses plugins, helper DLLs, or side-loaded components so policy exceptions do not become permanent trust gaps.
- Review trusted software as a supply chain object Treat signed executables, bundled libraries, and adjacent runtime files as one control surface when assessing software provenance and endpoint execution risk.
Key takeaways
- DLL sideloading exploits a gap between trusted launch and trusted execution, allowing malicious code to run beside a legitimate Windows application.
- The CPU-Z case is a useful reminder that supply chain abuse can succeed without replacing the main binary, which makes runtime dependency control essential.
- Practitioners should extend allowlisting and provenance checks to libraries, plugins, and search paths, not only the signed executable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The article is about trusted software being abused through a third-party dependency path at runtime. |
| NHI-10 — Human Use of NHI | Attackers rely on human trust in an approved executable to execute untrusted code through it. | |
| Recommendation — Map sideloadable runtime dependencies to NHI-03 and restrict what trusted binaries can load. Separate human approval of software from the machine trust granted to its loaded components. | ||
| MITRE ATT&CK | TA0002;TA0005;TA0008 — Execution; Defense Evasion; Lateral Movement | DLL sideloading is an execution technique that also evades simple allowlisting assumptions. |
| Recommendation — Hunt for execution paths that rely on search-order abuse and map them to ATT&CK technique chains. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Runtime-loaded components and adjacent files need to be inventoried to govern the software estate. |
| Recommendation — Inventory application components and block unapproved binaries and libraries from executing. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Least functionality supports denying unnecessary libraries, plugins, and runtime code paths. |
| Recommendation — Use CM-7 to restrict unnecessary components and reduce executable loading surface. | ||
Key terms
- DLL Sideloading: A technique where a legitimate executable loads a malicious library from a location the application checks before the real system path. It works because the program’s trust is inherited by the code it loads, which makes execution control as important as file reputation.
- Search-Order Hijack: A search-order hijack is a technique that places a malicious or planted module where a process will find and load it before the legitimate one. In practice, attackers abuse trusted directories and load behavior to redirect execution, which can turn a normal library lookup into code execution or privilege escalation.
- Application Allowlisting: Application allowlisting is the practice of permitting only approved software to run or be installed on a device. It reduces the chance of malicious or unmanaged apps changing the device’s behaviour, and it is especially useful where mobile endpoints must remain tightly governed.
- Device Trust Boundary: The device trust boundary is the point where an endpoint is considered sufficiently verified to access systems, data, or services. It defines the security line between trusted and untrusted device states, based on posture, identity, integrity, and policy. In practice, it governs whether a device can authenticate, connect, or receive sensitive access.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to runtime trust decisions across modern security programmes.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org