A critical vulnerability in Docker Desktop for Windows and macOS, designated CVE-2025-9074, has been patched after it was discovered that the software’s internal API was improperly exposed and accessible without authentication from within containers. This flaw, with a CVSS v3.1 score of 9.3, allows an attacker to achieve full host compromise by running a malicious container, completely bypassing Docker’s security model and isolation guarantees, including the Enhanced Container Isolation (ECI) feature1. The vulnerability was discovered accidentally by researcher Felix Boulet and independently confirmed on macOS by Philippe Dugre of Pvotal Technologies2.
Executive Summary for Leadership
This vulnerability represents a severe risk to development and continuous integration/continuous deployment (CI/CD) environments. An attacker with any level of access inside a container—potentially gained through a compromised application, a malicious image, or even a Server-Side Request Forgery (SSRF) vulnerability—could leverage this flaw to escape the container and gain full control of the underlying Windows or macOS host. The primary mitigation is immediate patching. Docker Inc. has released a fix in Docker Desktop version 4.44.3, which restricts access to the vulnerable internal API endpoint. No active exploitation in the wild has been reported at this time.
- CVE Identifier: CVE-2025-9074
- Affected Software: Docker Desktop for Windows and macOS (versions prior to 4.44.3)
- Severity: Critical (CVSS v3.1 Score: 9.3)
- Primary Risk: Full host operating system compromise from within a container.
- Key Mitigation: Update Docker Desktop to version 4.44.3 or later immediately.
Technical Mechanism of the Vulnerability
The core of the vulnerability was an improper access control flaw within Docker Desktop’s architecture. The software’s internal API, which manages the Docker Engine, was bound to a static internal IP address, `http://192.168.65.7:2375/`1, 2. This endpoint was left completely unauthenticated and, critically, was reachable from within any Linux container running on the host. This access was possible regardless of whether the Enhanced Container Isolation (ECI) setting was enabled or if the TCP port 2375 was explicitly exposed to the network, making it a default insecure configuration. The exposure of this API endpoint provided a direct path to interact with the Docker Engine, the core component responsible for managing containers.
Proof of Concept Exploitation
The exploitation path is straightforward and was demonstrated by researcher Felix Boulet. From within a running container, an attacker needs to execute only two HTTP requests to the vulnerable API endpoint to achieve host compromise. The first request creates a new, privileged container that mounts the host’s filesystem, and the second request starts that container. Cybersecurity News published a proof-of-concept (PoC) using common command-line tools available in a minimal Alpine Linux container2.
The PoC code, as reported, is as follows:
“`bash
# From within a container, using wget to exploit the vulnerability
wget –method=POST –header=’Content-Type: application/json’ –body-data='{“Image”:”alpine:latest”, “Cmd”:[“sh”, “-c”, “echo ‘Exploit succeeded’ > /host_root/tmp/poc.txt”], “HostConfig”:{“Binds”:[“C:/:/host_root”], “Privileged”:true}}’ http://192.168.65.7:2375/containers/create
# Then, start the created container using the ID returned from the first command
wget –method=POST http://192.168.65.7:2375/containers/
“`
This simple script would result in the attacker having full read/write access to the host’s `C:\` drive, with the same permissions as the user running Docker Desktop.
Impact and Attack Vectors
The impact of this vulnerability is extensive. On Windows systems utilizing the WSL2 backend, successful exploitation could lead to a full SYSTEM-level compromise of the host machine. On macOS, attackers would gain highly privileged access. A particularly concerning attack vector is that this vulnerability can be triggered via a Server-Side Request Forgery (SSRF) flaw2. This means a web application vulnerability within a container could be enough to launch the attack, significantly widening the potential attack surface beyond just malicious images. Furthermore, this flaw did not require the Docker socket (`/var/run/docker.sock`) to be mounted into the container, a common misconfiguration that this exploit cleverly avoids, making it a threat even to more securely configured environments.
Patch, Mitigation, and Historical Context
Docker Inc. has addressed this critical issue in Docker Desktop version 4.44.3. The update restricts access to the internal API endpoint, preventing unauthorized interaction from containers. The patched version is available for all supported platforms, including Windows, Windows ARM, macOS (Intel and Apple Silicon), and major Linux distributions1. While updating is the only complete remedy, implementing strict network segmentation and maintaining rigorous control over container images can help reduce the overall attack surface in an environment.
This incident is not an isolated one in the history of Docker Desktop security. It echoes past issues such as the remote code execution vulnerabilities in extension handling (CVE-2024-8695 & CVE-2024-8696) patched in September 20246 and a privilege escalation vulnerability in the Windows service (CVE-2020-11492) disclosed in May 20207. The recurrence of such flaws underscores the persistent attack surface presented by the complex architecture of tools that bridge host and containerized environments.
Relevance and Remediation Steps
For system administrators and security personnel, the immediate priority is to verify and update all instances of Docker Desktop to version 4.44.3 or later. This action should be treated with high urgency across all development, testing, and production environments where Docker Desktop is used. Security teams should scan their networks to inventory Docker Desktop versions and ensure compliance with the patch mandate.
For threat intelligence and security operations center (SOC) analysts, this vulnerability highlights a new technique for container escape and host compromise. Detection rules should be developed to look for network traffic from containers directed toward the internal IP `192.168.65.7` on port `2375`, as this would be a strong indicator of attempted exploitation. Monitoring for the creation of new privileged containers with host filesystem binds from unexpected processes could also serve as a valuable detection signal.
This vulnerability serves as a stark reminder of the shared responsibility model in cloud and containerized environments. While cloud providers secure the infrastructure, customers are responsible for securing their workloads, which includes keeping foundational tools like Docker Desktop patched and configured according to security best practices.
