Cloud Security

Docker Desktop CVE-2025-9074 Breaks Container Isolation

June 9, 2026 · 6 min read · By William

Unauthenticated API at the Core

CVE-2025-9074 is not a nuanced privilege escalation requiring a chain of coincidences. It is a straightforward architectural oversight: Docker Desktop exposes its internal Engine API at 192.168.65.7:2375 to every container, no authentication required. Any container — malicious or compromised — can reach that endpoint and issue commands to the Docker daemon as if it were the host user. The vulnerability carries a CVSS score of 9.3 and was patched in Docker Desktop 4.44.3, released August 2025. The Hacker News confirmed the fix and described the flaw as enabling full host compromise from within any container.

Security researcher Felix Boulet identified the root cause: the hardcoded subnet used by Docker Desktop’s virtual machine allows containers to route traffic directly to the Engine’s unauthenticated TCP listener. On Windows, the impact is devastating. On macOS, file system boundaries blunt the blow somewhat, but the attacker still gains full control over Docker’s own configuration. LinuxSecurity covered the dual-vulnerability patch that also addressed a related NVIDIA Container Toolkit flaw (CVE-2025-23266) in CDI mode.

How the Container Escape Works

The exploit path is almost trivially simple. A single HTTP POST to /containers/create binds the host’s C:\ drive into the new container at a mount point like /mnt/host/c:/host_root. A second POST to /containers/{id}/start executes a startup command that can read, modify, or destroy any file on the host — including credential stores, SSH keys, and configuration files.

PVOTAL Technologies researcher Philippe Dugre (zer0x64) demonstrated that an attacker can go further: by overwriting a system DLL through the mounted host filesystem, the container escalates to full administrator privileges on Windows. The entire chain requires no credentials, no Docker socket mount, and no user interaction. A proof-of-concept exploit is publicly available on GitHub, lowering the barrier for any threat actor with container access.

Stage	Action	Result
1	POST to /containers/create with host C:\ mounted	Arbitrary container spawned with host filesystem access
2	POST to /containers/{id}/start with payload command	Command executes with host-level file access
3	Overwrite system DLL or steal credentials	Full administrator compromise of Windows host

Enhanced Container Isolation Falls Short

Docker’s Enhanced Container Isolation (ECI) — marketed as a hardening layer for enterprise deployments — does not mitigate this vulnerability. Docker’s own advisory states this explicitly: “ECI does not mitigate this vulnerability.” For organizations that deployed ECI as a substitute for proper network segmentation between containers and the host daemon, this is a direct repudiation of that trust.

The lesson is structural. ECI restricts what a container can do at the OS level, but it does not control who can talk to the Docker API. When the API itself is exposed without authentication on a predictable internal address, container-level hardening becomes irrelevant. The attack bypasses the container boundary entirely by talking to the orchestration layer. This distinction — between securing the workload and securing the management plane — is one that too many teams conflate. It echoes earlier Docker isolation failures that exposed the same fundamental design weakness.

Windows Takes the Hardest Hit

The Windows attack surface is substantially worse than macOS. On Windows, Docker Desktop runs with administrative privileges and has broad filesystem access by default. Once a container escapes, the attacker operates as a full admin with no further privilege escalation needed. macOS benefits from a permission model that prompts the user before Docker accesses directories outside its allowed paths, which limits the damage of a raw filesystem mount.

But macOS is not safe. As Dugre noted, an attacker who controls Docker can still backdoor the application by mounting and modifying its configuration — no user approval required. The attacker may not get host root, but they get persistent control over every container, image, and volume on that machine. For developer workstations that hold cloud credentials, API keys, and git tokens in container environment variables, that level of access is more than enough.

Linux is unaffected by this specific flaw because the Linux version of Docker Desktop uses a named pipe for the Engine API rather than a TCP socket bound to a reachable IP. The design difference is accidental, not intentional — but it happens to prevent the exact attack described here.

SSRF Opens a Second Front

Direct container compromise is the most obvious attack path, but it is not the only one. Any application running inside a container that is vulnerable to server-side request forgery (SSRF) can be leveraged to reach the Docker Engine API at 192.168.65.7:2375. If the SSRF supports POST requests — and some do — the full escape chain applies without the attacker ever needing to deploy their own container.

This makes CVE-2025-9074 a compound risk. It is not just a container isolation bug. It is a latent backdoor in the Docker Desktop networking stack that turns any SSRF vulnerability in any containerized application into a host compromise. The blast radius extends well beyond the individual container boundary.

What Your Team Must Do Now

First, update Docker Desktop to version 4.44.3 or later on every Windows and macOS workstation in your fleet. This is non-negotiable. The patch is available, the PoC is public, and the exploit is simple enough to be weaponized by any competent threat actor.

Second, audit your container images for SSRF vulnerabilities. If you are running web-facing applications in Docker Desktop containers — even in development — an SSRF in that application now has a direct path to host compromise. Scan with tools that understand container network topologies, not just application-level flaws.

Third, stop treating container isolation as a security boundary on developer workstations. It is a convenience feature. Docker Desktop was designed for developer ergonomics, not for multi-tenant security. Any workflow that processes untrusted input inside a Docker Desktop container on Windows or macOS should be re-evaluated. Consider using remote Docker hosts or hardened VMs for sensitive workloads. IBM X-Force data shows cloud application exploitation surged 44% in 2026, and developer endpoint compromises are a primary vector.

Fourth, review your CI/CD pipelines. If your build agents run Docker Desktop on Windows and pull third-party images or execute untrusted build scripts, those agents are vulnerable. An attacker who compromises a build container can escape to the build agent host and pivot to your source code, secrets, and deployment infrastructure. The pattern mirrors the Vitest RCE chain where widely-used development tools became the attack vector.