Full Report
The Docker internal HTTP API is used to control most of Docker. Exposing this is an automatic game over in terms of container security. This is because you can start a privileged container that has access to the full host. The author of this post was internally mapping the localhost interface on the VM out of paranoia on Docker Desktop for Windows. While doing this, they found that they could access the Docker API from the container. This exploit is so bad that it works from an SSRF vulnerability. It's fascinating that this issue has existed for so long without being noticed before. According to the author, Docker doesn't have a security program, which may be part of the reason this is the case. Regardless, fantastic impact on this bug!
Analysis Summary
# Vulnerability: Unauthenticated Remote Access to Docker API Leading to Full Host Escape on Docker Desktop for Windows
## CVE Details
- CVE ID: CVE-2025-9074
- CVSS Score: *Score not explicitly provided in the text, but impact suggests High/Critical.*
- CWE: CWE-284 (Improper Access Control)
## Affected Systems
- Products: Docker Desktop for Windows
- Versions: Prior to 4.44.3
- Configurations: Default installation configuration, where the internal Docker HTTP API is accessible from within running containers.
## Vulnerability Description
The vulnerability resides in the Docker Desktop for Windows implementation where the internal Docker HTTP API (exposed on the localhost interface address, e.g., `192.168.65.7:2375`) was reachable from *any* running container without requiring any form of authentication or access controls. This allows an attacker, via SSRF from within a compromised container, to communicate directly with the host's Docker daemon. This communication allows the attacker to create and start a new, privileged container, mounting the host's `C:` drive, thereby achieving full read/write access to the underlying Windows host operating system.
## Exploitation
- Status: PoC available (Exploitation confirmed via two specific HTTP POST calls)
- Complexity: Low (Can be executed via simple `wget` commands from within any container)
- Attack Vector: Adjacent (Communication originating from a container environment to the host's internal API)
## Impact
- Confidentiality: High (Full access to the host's file system)
- Integrity: High (Ability to modify or delete host files, execute arbitrary commands via mounting)
- Availability: High (Potential for complete system compromise and shutdown)
## Remediation
### Patches
- Docker Desktop version **4.44.3** and later.
### Workarounds
- Enforce strict network segmentation around containers.
- Apply zero-trust principles within the host environment.
- Ensure no workloads can easily scan or reach the internal Docker configuration network addresses (e.g., `192.168.65.7`).
## Detection
- **Indicators of Compromise (IoCs):**
- Unexpected outbound connections from containers targeting internal Docker API endpoints (e.g., `192.168.65.7:2375`).
- Creation of new, highly privileged containers originating from potentially untrusted sources.
- Creation of files on the host's `C:` drive originating from container processes (e.g., `/host_root/pwn.txt` in the POC scenario).
- **Detection Methods and Tools:**
- Network monitoring tools configured to profile traffic originating from containers to internal/localhost interfaces.
- Runtime security tools monitoring Docker API calls for unauthenticated access or suspicious calls like `/containers/create` with host mounts (`Binds`).
## References
- Vendor Advisory (Release Notes): hxxps://docs.docker.com/desktop/release-notes/#4443
- CVE Record: hxxps://www.cve.org/CVERecord?id=CVE-2025-9074
- Researcher Write-up: hxxps://pvotal.tech/breaking-dockers-isolation-using-docker-cve-2025-9074/
- Proof Video: hxxps://blog.qwertysecurity.com/Articles/blog3.html#videopoc