Docker Desktop closes an internal network route to the Engine API

A container can acquire control of other containers if it can reach an unauthenticated management API. Protecting a Unix socket mount does not close a separate TCP route to that API. CVE-2025-9074 exposes exactly that distinction in Docker Desktop's internal networking.

Docker's August 20 release notes for 4.44.3 say a malicious container could access the Engine and launch additional containers without having the Docker socket mounted. The Docker-issued CVE record, published the same day, identifies the route through the configured Docker subnet.

I regard Docker's portable image format as a useful way to define what software a container receives. That definition does not establish the authority the container can reach over a network. This disclosure matters because it lets a workload cross from executing its own application into controlling the service that manages applications.

The reachable resource is a management interface

The advisory describes local running Linux containers accessing the Engine API at 192.168.65.7:2375 by default. The address belongs to the configured Docker subnet. What matters is the container's access to the management service, not an application port deliberately published for external clients.

The record says the API access can enable privileged commands, including controlling other containers, creating new containers, and managing images. Those are engine-level operations. A process able to submit them gains authority beyond the filesystem and process definition of its original container.

That is why the absence of a socket mount does not establish safety against this vulnerability. A socket path is one way to reach the API. This flaw provides a network route. Removing the first route does not remove the second, because they are different objects subject to different access controls.

The public record identifies the endpoint and the resulting authority. It does not publish a detailed description of the repaired implementation. It would therefore be speculative to assign the defect to a particular internal proxy function or to claim that a specific packet filtering rule is the complete fix.

The supported conclusion is narrower and sufficient. A running Linux container could access an Engine API that it should not have been able to control. Desktop 4.44.3 is the fixed release named by Docker. The release note ties the update directly to removing that unauthorized access path.

ECI does not mitigate this path

Docker explicitly states that Enhanced Container Isolation does not mitigate CVE-2025-9074. The CVE record says the issue occurs with or without ECI enabled. A security description that treats enabling ECI as the remedy would directly contradict the supplier's advisory.

The reason this qualification matters can be understood without inventing ECI implementation details. Isolation controls may limit what a process can do through one interface. A separate interface that accepts management commands can give that process a different way to request the result.

In this case, the API can create another container. An attacker does not need every forbidden operation to become available inside the original container if the management service will perform sufficiently powerful operations on its behalf. The relevant boundary includes the service's authority and the workload's ability to invoke it.

This is a general property of management interfaces, but the evidence here is specific. Docker names container creation and control as possible consequences, and separately says ECI does not prevent the vulnerability. Those statements establish that the original container's configured isolation is not the complete description of its reachable authority.

The distinction also helps interpret a configuration review. Seeing no Docker socket mount answers a question about mounts. Seeing ECI enabled answers a question about that control. Neither observation, under this advisory, answers whether the affected network endpoint is reachable from a container.

The localhost exposure option is a separate setting

The CVE record also says exploitation does not depend on enabling the option to expose the daemon on tcp://localhost:2375 without TLS. This occurs whether that option is enabled or disabled. The familiar warning about an exposed local daemon is therefore not the prerequisite for this particular vulnerability.

Two endpoints can share a port number without representing the same access arrangement. The advisory's route is through the configured Docker subnet. A setting naming localhost does not, by its label alone, describe every internal listener or every path a managed container can use.

This matters because a user could reasonably look for the obvious exposure option and find it disabled. In an affected version, that observation would not remove the CVE's stated conditions. The supplier's description explicitly closes off that interpretation.

The same reasoning applies to transport and authorization. A route being internal to a product's networking arrangement does not make every process using it authorized to control the product. A workload can be inside the managed environment while still being untrusted with respect to its management operations.

My preference for small images is relevant only to part of that problem. Reducing installed tools can reduce what an application carries, but the management service's authority exists outside the image. Image minimality cannot be treated as proof that a reachable API will reject unauthorized commands.

Host file access depends on the environment

The release notes warn that the flaw could allow unauthorized access to user files on the host. Docker's CVE description gives a specific example. On Windows using the WSL backend, some circumstances permit mounting the host drive with the privileges of the user running Desktop.

That scope should remain attached to the consequence. The advisory does not say every platform grants unrestricted operating system administrator access through the same sequence. It describes user-level host-drive access in a particular arrangement and broad Engine control as the underlying capability.

The user privilege qualification is still substantial. A process that can access files with the Desktop user's authority can reach data outside the filesystem assigned to the malicious workload. The original container mount list no longer describes all the files the attacker may arrange to access.

This also distinguishes the failure from simply reading a file that was intentionally shared with a container. The advisory describes using Engine authority to create additional access. The change in authority comes before the resulting file access.

The affected product entry spans Desktop versions beginning at 4.25 and earlier than 4.44.3. Docker lists Windows, macOS, and Linux in that entry. The Linux-container wording identifies the initiating workload, and should not be confused with a claim that the product scope is only a native Linux Engine installation.

Docker assigns the issue a CVSS 4.0 base score of 9.3 and labels it Critical. The score accompanies a local attack classification in the record. Local describes the initiating position in this scenario, which is a workload already running on Desktop. It does not restrict the consequences to files inside that workload. The subsequent access to Engine operations is precisely why the resulting impact can extend beyond the initiating container and into resources managed by the surrounding product.

The fixed product version is Desktop 4.44.3

The release identifier matters because Desktop includes several components with their own versions. A daemon version alone does not establish that the Desktop networking issue is fixed. Docker identifies Desktop 4.44.3 as the product release addressing this CVE.

Likewise, the presence of an application image built after the disclosure does not identify the surrounding Desktop version. Rebuilding a workload changes its artifact. Updating Desktop changes the product responsible for the affected route. They concern different parts of the execution environment.

The public advisory establishes a possible attack path, not evidence that every affected machine has been attacked. A malicious workload must be running in the relevant environment. The record's impact statement explains what that workload can gain through the exposed management API.

That still gives the update a concrete purpose. It closes a route through which a workload can ask the engine to perform operations beyond its intended role. Avoiding a socket mount, enabling ECI, and disabling the localhost exposure setting do not substitute for the fixed release under Docker's stated conditions.

For someone running third-party workloads locally, the useful security model must include reachable management services. The image describes application content and mounts describe selected filesystem access. In this vulnerability, a separate network endpoint supplied enough authority to create additional containers and, in some environments, arrange access to host files. Desktop 4.44.3 addresses that endpoint exposure as a product-level security fix.