Docker has released fixes to address a critical security flaw affecting the Docker Desktop app for Windows and macOS that could potentially allow an attacker to break out of the confines of a container.
The vulnerability, tracked as CVE-2025-9074, carries a CVSS score of 9.3 out of 10.0. It has been addressed in version 4.44.3.
“A malicious container running on Docker Desktop could access the Docker Engine and launch additional containers without requiring the Docker socket to be mounted,” Docker said in an advisory released last week.
“This could allow unauthorized access to user files on the host system. Enhanced Container Isolation (ECI) does not mitigate this vulnerability.”
According to security researcher Felix Boulet, the vulnerability has to do with how it’s possible for a container to connect to the Docker Engine API at 192.168.65[.]7:2375 without requiring any authentication, thereby opening the door to a scenario where a privileged container could gain full access to the underlying host upon mounting the C: drive into it.
In a proof-of-concept (PoC) exploit, a web request from any container has been found to trigger the flaw and result in a full compromise of the host –
- POST a JSON payload to “/containers/create,” binding the host C: drive to a folder in the container (/mnt/host/c:/host_root) in the container, and using a startup command to write or read anything under /host_root on container startup.
- POST to “/containers/{id}/start” to launch the container and start the execution
“At its core, this vulnerability was a simple oversight, Docker’s internal HTTP API was reachable from any container without authentication or access controls,” Boulet said.
PVOTAL Technologies researcher Philippe Dugre (“zer0x64”), who further examined the flaw, said an attacker can exploit the flaw on the Windows version of Docker Desktop to mount as an administrator the entire file system, read any sensitive file, and overwrite a system DLL to escalate the attacker to administrator of the host system.
“On macOS, however, the Docker Desktop application still has a layer of isolation and trying to mount a user directory prompts the user for permission,” Dugre said. “By default, the Docker application does not have access to the rest of the file system and does not run with administrative privileges, so the host is a lot safer than in the Window’s case.”
“However, the attacker does still have full control of the Docker application/containers and can even backdoor it by mounting and modifying the application’s configuration, which does not need any user approval.”
The vulnerability does not impact the Linux version since Linux uses a named pipe on the host’s file system, rather than relying on a TCP TCP socket for the Docker Engine’s API.
The easiest way to leverage the vulnerability is via a threat actor-controlled malicious container. That said, a server-side request forgery (SSRF) flaw can be used as an alternate attack vector.
“This vulnerability allows an attacker to proxy requests through the vulnerable application and reach the Docker socket, the impact of which varies especially depending on the availability of HTTP requests methods (most SSRF only allows GET requests, but some niche case allows the use of POST, PATCH, DELETE methods),” Dugre said.
