CVE-2025-9074: Docker Desktop Vulnerability Allows Host Compromise

Containers are designed to provide isolation, but a newly disclosed flaw shows just how fragile that boundary can be when misconfigurations slip through. A critical vulnerability in Docker Desktop, tracked as CVE-2025-9074, demonstrates how a seemingly small oversight can lead to full host compromise. This discovery has already been patched, but the details are worth understanding both for defenders and for anyone running untrusted workloads locally.

What is CVE-2025-9074?

CVE-2025-9074 (CVSSv4: 9.3) is a Server-Side Request Forgery (SSRF) vulnerability affecting Docker Desktop on Windows and macOS. The flaw allows an attacker to escape a container and access the host system.

CVE-2025-9074 (CVE Radar – SOCRadar Labs)

The vulnerability originates from an exposed Docker Engine API. From inside any container, requests could be sent to http://192.168.65.7:2375/ without authentication. This API, intended only for Docker’s control plane, grants powerful capabilities like creating and starting containers, or mounting volumes. In practice, this meant that a malicious or compromised container could escalate privileges, bind host directories, and manipulate host files directly.

Moreover, Enhanced Container Isolation (ECI) does not mitigate this flaw, as cited in Docker’s release note.

Proof of Concept: How the Exploit Works

In a Proof-of-Concept (PoC) exploit for CVE-2025-9074, researcher Felix Boulet showed how a container could escape isolation using just two HTTP POST requests:

1. Create a new container by sending a request to /containers/create.
   • The payload specified a volume bind that mapped the Windows host’s C: drive into the container.
   • A simple command (e.g., writing to a file in the mounted directory) was included to prove access.
2. Start the container using a request to /containers/{id}/start.
   • Once launched, the container had full access to the mounted filesystem path, effectively giving the attacker control of host files.

Because the Docker API was exposed to containers without authentication, this attack could also be chained from a Server-Side Request Forgery (SSRF) in a web application running inside Docker. In other words, no direct code execution inside the container was necessary – an SSRF alone could proxy malicious API calls to Docker’s control plane.

Security engineer Philippe Dugre validated the exploit independently. On Windows, he showed that attackers could overwrite system DLLs to escalate privileges to administrator. On macOS, the damage was reduced but still allowed backdooring of Docker’s configuration and workloads.

SOCRadar’s Vulnerability Intelligence: Latest CVEs & Hacker Trends

Addressing vulnerabilities like CVE-2025-9074 requires more than just patching; it requires visibility and intelligence. SOCRadar provides two modules that can help strengthen defenses:

• Attack Surface Management (ASM): Continuously monitor your external-facing assets, identify exposed services like open Docker APIs, and reduce risks before attackers can exploit them.
• Cyber Threat Intelligence – Vulnerability Intelligence: Gain timely, actionable insight into emerging vulnerabilities. Prioritize patching and mitigation with context-rich intelligence that shows how threats are being exploited in the wild.

CVE-2025-9074 Impact on Windows vs. macOS vs. Linux

On Windows, the impact is most severe. Because Docker Desktop relies on WSL2 (Windows Subsystem for Linux 2), an attacker can mount the entire filesystem with administrative privileges. This enables them to:

• Read sensitive user and system files.
• Overwrite system DLLs.
• Escalate to full administrator rights on the host.

While still affected, macOS enforces additional security layers. Attempts to mount directories typically trigger a user consent prompt, and Docker does not run with root-level privileges by default. However, attackers could still:

• Control the Docker application.
• Backdoor container environments.
• Modify Docker configuration files without needing approval.

Docker Desktop on Linux is not affected. The reason lies in its architecture: Linux uses a Unix socket for Docker Engine communication rather than an open TCP port, preventing this particular exploit scenario.

Patching and Mitigation Steps

Docker responded quickly after the responsible disclosure. The vulnerability is patched in Docker Desktop version 4.44.3.

Recommended actions:

• Update immediately to Docker Desktop 4.44.3 or later.
• Review container isolation settings to ensure workloads do not assume host protection by default.
• Apply zero-trust principles to local development environments, treating internal APIs as potential attack vectors.
• Audit container workloads. Be cautious when running untrusted code, even in seemingly isolated setups.