Docker Desktop has been hit with a high-severity security finding: a server-side request forgery (SSRF) flaw in Docker Desktop for Windows and macOS that allows a malicious container to reach the Docker Engine API and launch additional containers on the host. The vulnerability, tracked as CVE-2025-9074 and scored 9.3 (Critical), can be exploited without mounting the Docker socket inside the container and is not mitigated by Docker’s Enhanced Container Isolation (ECI), the vendor says.
Docker’s advisory states the core problem plainly: “A malicious container running on Docker Desktop could access the Docker Engine and launch additional containers without requiring the Docker socket to be mounted. This could allow unauthorized access to user files on the host system. Enhanced Container Isolation (ECI) does not mitigate this vulnerability.”
How the Docker Desktop SSRF Vulnerability Operates
The issue hinges on an unauthenticated internal endpoint. Researcher Felix Boulet discovered that, from inside any running container, the Docker Engine API could be reached at http://192.168.65.7:2375/. Using that reachable endpoint, Boulet’s proof-of-concept demonstrated the ability to create and start a new container that binds the Windows host’s C: drive into the container filesystem. The PoC reportedly accomplished the container creation and start sequence by issuing two HTTP POST requests using wget.
Notably, Boulet’s exploit does not require code execution privileges inside the malicious container; the attack leverages the SSRF to talk directly to the engine API and orchestrate host-level changes. In effect, a compromised or malicious container can act as a proxy into the Docker control plane and request operations that should be restricted.
Windows Versus macOS Versus Linux: Different Risk Profiles
Independent validation from Philippe Dugre, a DevSecOps engineer and security challenge designer, confirmed the vulnerability affects Docker Desktop on Windows and macOS but not the native Linux release. The reason for the discrepancy lies in how Docker Desktop is implemented across operating systems.
On Windows, Docker Desktop uses WSL2 as the runtime. Dugre explains the practical consequence: through the Docker Engine running under WSL2, an attacker can mount the Windows filesystem with administrative privileges, read sensitive files, and potentially overwrite system DLLs — a path that could escalate to full administrator control of the host. Dugre summarized the Windows impact: mounting the filesystem and overwriting a system DLL could result in an escalated administrator compromise.
On macOS, Dugre found more friction. The Docker Desktop application operates with a tighter layer of OS-level protections, and attempts to write into a user’s home directory typically trigger a permission prompt. By default, Docker on macOS does not possess unrestricted access to the entire filesystem nor elevated administrative privileges, which limits the immediate blast radius of a container-driven engine compromise. Still, Dugre cautioned that the attacker still controls the application and containers, leaving room for other malicious changes such as backdooring the Docker Desktop app or altering configuration files without obvious prompts.
The Linux distribution of Docker Desktop is reportedly not affected, likely because its architecture does not expose the same internal API address or authentication gap that the Windows and macOS builds did.
Exploit Simplicity and Proofs of Concept
Dugre stressed the exploit’s ease of use; his validation showed a working exploit reduced to a short script — reportedly as brief as three lines of Python in one test. Boulet’s PoC used two wget POST requests to create and start a container that binds host storage. The low code complexity combined with an unauthenticated API endpoint explains the critical severity rating and the urgency of vendor remediation.
Vendor Response and Patch Release
Docker received the report through responsible disclosure channels and issued an update to Docker Desktop to address the vulnerability. The vendor released Docker Desktop version 4.44.3, which contains the fixes intended to close the SSRF exposure. Docker’s bulletin also reiterated that existing ECI protections do not mitigate this flaw, underlining that the fix required a change to how the desktop product exposes and secures its internal APIs.
Enterprise Implications and Observations
CVE-2025-9074 highlights a specific class of risk in desktop container platforms: when the control plane or engine is reachable from untrusted workloads, traditional container isolation guarantees can fail. The Windows case, where Docker Desktop runs atop WSL2, demonstrates how platform integration decisions affect the threat model and attack surface. The macOS constraints show that OS-level permission prompts can raise the bar for exploitation but do not eliminate risk entirely.
The vulnerability’s combination of an unauthenticated internal API, trivial exploit code, and the ability to bind host storage into a container produced a critical-rated issue that warranted a rapid fix. Docker’s release of 4.44.3 is the vendor action documented publicly to remediate that specific SSRF pathway.
What the Researchers Said
Felix Boulet’s findings centered on the reachable engine API at http://192.168.65.7:2375/ from containers and the consequences of unauthenticated calls. Philippe Dugre emphasized the differing risk models across operating systems and noted that while macOS added friction, Windows allowed direct filesystem mounts through WSL2 that could escalate to administrator privileges.
Dugre also described the exploit as straightforward to weaponize, noting the short size of test exploits and the lack of need for in-container code execution privileges to trigger host-level actions.
Timeline and Disclosure
The vulnerability was reported through coordinated disclosure. Docker acknowledged the issue and released the patched Docker Desktop 4.44.3. Public notices from Docker warned that ECI would not mitigate the flaw and provided the high-level vulnerability details and CVE assignment (CVE-2025-9074, score 9.3). Security researchers published proof-of-concept descriptions and validation results that confirmed both the severity and the platform-specific behaviors.
CVE-2025-9074 — the Docker Desktop SSRF vulnerability — demonstrated how an unauthenticated internal API endpoint reachable from containers can let a malicious container instruct the engine to launch additional containers with host bindings. The flaw affected Windows and macOS builds of Docker Desktop, presented a significantly higher impact on Windows due to WSL2 behavior, and was rated critical. Docker addressed the issue in Docker Desktop 4.44.3 following researcher disclosures that included compact proof-of-concept exploits.
