Docker Desktop fixes DLL search order in its Windows installer

A legitimate installer can execute the wrong library if its dependency search reaches a writable directory before the intended system location. Docker Desktop's Windows installer had that problem. CVE-2025-9164 describes required DLLs being sought in the user's Downloads folder before system directories, allowing malicious DLL placement to become local privilege escalation.

Docker lists the repair in Desktop 4.49.0, released October 23. Its CVE record was published October 27, which is the date used here so the description includes the published affected-version information. The record identifies Docker Desktop through 4.48.0 on Windows as affected.

I tend to judge Docker through its build files and final runtime images. This issue belongs to the installation path that makes those workflows available. A reduced application image cannot address a dependency that the host installer loads before the application environment exists.

A library name is not a complete dependency identity

Docker's description identifies the search order as the failure. The installer requires a DLL, and the loader chooses a file from the locations it searches. If an attacker can place a matching file in an earlier location, the requested name can resolve to attacker-controlled code.

Microsoft's DLL search-order documentation explains the underlying distinction. Supplying a full path identifies a particular location. Otherwise, the loader uses a search process that can depend on application type, loaded modules, and configuration.

The security consequence concerns the chosen file. A program can have a legitimate executable while selecting an unintended dependency at runtime. Identifying the installer itself is therefore insufficient to identify every piece of code it may load through a name-based search.

The Docker advisory makes Downloads the relevant location in this case. It does not require an attacker to replace a DLL in a protected system directory. The earlier search location provides the opportunity to substitute a different implementation before the system directory is checked.

That distinction changes the privilege analysis. A user-writable location can be appropriate for downloaded files without being an appropriate source for code loaded by a more privileged process. The vulnerability arises when the installer crosses that boundary during library resolution.

The public description does not name every affected DLL or specify the exact loader call used by the installer. Those details should not be supplied from assumptions about how Windows installers are usually implemented. The supported mechanism is insecure search order and malicious placement in the named directory.

Elevation turns dependency selection into a security boundary

Microsoft's DLL security guidance describes this class as DLL preloading or binary planting. If a malicious library is found before a legitimate one, the application loads it. When the application runs with administrator privileges, that can produce local privilege elevation.

Docker's record describes the outcome as local privilege escalation. The attacker-controlled DLL becomes part of the installer process's execution, so the consequence depends on that process's authority. The attacker gains value by causing a more privileged process to select code from a location the attacker can influence.

This is distinct from a defect in a service running inside a container. The Windows installer is the affected operation. A container workload need not be the initiating component in the public description.

The distinction also separates installation from ordinary application startup. An installed copy of Desktop and a downloaded installer are related artifacts with different roles. Knowing the running application version does not by itself establish which installer executable someone may later launch.

For example, retaining an old installer in Downloads leaves an old executable available for future use. Installing a fixed application release does not logically rewrite every separately stored copy of an earlier installer. That is an artifact-lifetime consequence, not an additional vulnerability claimed by the advisory.

The relevant replacement is therefore the fixed installer when performing an installation or update. Docker identifies 4.49.0 as the release containing the repair. Its advisory does not present a container configuration flag that alters the old installer's library selection.

The Downloads directory has two different roles

Downloads is useful as a place to receive files. That role does not imply that its contents are trustworthy executable dependencies. The Docker issue makes those two roles collide when the installer searches there before checking system directories.

A downloaded executable may be expected to run from a user-controlled location. The security question is whether unrelated neighboring files can influence which libraries it loads. An installer can be the intended executable while an adjacent library remains an unintended input.

That is why evaluating only the installer file misses the complete operation. The resolved dependency set includes files outside the executable. If the resolution rule accepts a neighboring file, the directory's write permissions become part of the code-loading decision.

The advisory's account is concrete enough to explain that relationship without demonstrating an exploit. An attacker needs a placement opportunity, a library name that the installer requests, and an affected invocation. The release notes establish the vulnerable search location and resulting escalation class.

It would be inaccurate to say that every file in Downloads executes during installation. Search-order hijacking concerns a file selected as a requested dependency. The attack relies on matching a resolution operation, not on the installer running the directory's contents indiscriminately.

It would also be inaccurate to describe this as a remote compromise merely because installers are downloaded. Docker classifies a local privilege escalation mechanism involving malicious DLL placement. The public description does not establish a network service accepting an unauthenticated request and executing it directly.

The published score retains its conditions

Docker assigns the issue a CVSS 4.0 score of 8.8 and a High severity. The vector identifies local access, low privileges, high attack complexity, and additional attack requirements. Those qualifications belong with the score when describing the issue.

A severity value summarizes a defined scenario. It does not erase the requirement to place a malicious DLL where the affected installer searches. The score's impact assessment concerns what can happen once the search-order condition results in unintended code loading.

The advisory credits Mahmoud NourEldin as finder. Its affected product entry ends at 4.48.0, while the 4.49.0 release notes name the correction. Those two sources give a consistent version boundary without requiring an inference from an unrelated Engine release.

My preference for explicit build inputs makes this class of defect easy to recognize conceptually. A named dependency resolved through mutable directories is less explicit than a dependency whose source location is constrained. The same concern applies here before a Dockerfile or image enters the workflow.

That observation should not be mistaken for a claim that Docker used a particular mitigation API. The available release material says the vulnerability is fixed, but it does not document the exact implementation change. A source-level explanation of the patch would require evidence beyond the public description read here.

The fixed release changes the installation path

The 4.49.0 notes contain other changes, including a Docker Engine update and fixes to forwarded UDP ports. Those are separate from the Windows installer vulnerability. Combining them into a single claim about container runtime security would make the affected operation harder to identify.

The same release notes announce the end of support for Windows 10 21H2 and Windows 11 22H2, with newer minimum versions required in the next release. That compatibility notice concerns the supported host environment. It is separate from the affected installer version range in the CVE, so those two version checks should not be collapsed into one.

For this issue, the useful version is the Desktop installer release. The operating system scope is Windows, and the critical dependency is a required DLL selected through an insecure search order. The user's running application workload does not define that loader behavior.

This is also why a small final image is not a defense against this particular flaw. The image contents and the installer dependency set belong to different execution stages. The host must install or update the product before its container isolation settings can govern a workload.

The public record supports a specific repair and a specific remaining distinction. Desktop 4.49.0 supplies the fix, while separately retained earlier installers remain their own artifacts. The software selected for an installation includes the installer executable and the libraries it resolves, so the fixed installation path needs to constrain that complete code-loading operation.