Users of Docker Desktop on Windows and Mac are urged to upgrade to the latest version to patch a critical vulnerability that could allow an attacker to break the container isolation layer and potentially take over the host system. The flaw could also be exploited remotely through server-side request forgery (SSRF) attacks against web applications that run inside a Docker container.
The vulnerability, tracked as CVE-2025-9074, was found by a security researcher named Felix Boulet and affects Docker Desktop on Windows and Mac, but not the Linux version. It was patched in Docker version 4.44.3 released on Aug. 20.
“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 wrote in a blog post after the patch was released. “It’s a stark reminder that critical security gaps often stem from the most basic assumptions. I found this issue by running a quick nmap scan against the Docker’s documented private network.”
Docker management API lacked protections
The vulnerability stems from the fact that Docker Desktop exposes the Docker Engine API, which is used to control Docker containers over a TCP socket that can be accessed over the internal network from within containers and has no authentication.
Boulet, who is not a Docker specialist, said he found the vulnerability by mistake when running network scans on his own Docker environment. He then reached out to another researcher, Philippe Dugre from Pvotal Technologies, who had more experience with Docker to see whether the issue could be replicated. Dugre confirmed the flaw on a fresh macOS installation of Docker in default configuration.
“The Docker Engine socket should never be accessible by untrustworthy code or user,” Dugre wrote in a blog post. “This socket is the management API for docker and having access to it grants full access to everything the docker application can do. This obviously includes creating and deleting containers, but a more nefarious capability here is volume mounting.”
As a result of this flaw, an attacker who gains access to a Docker container could leverage the API to create a new Docker container and give it access to a volume that hosts, for example, a database used by a different container, therefore exposing sensitive information.
But more critically, the attacker could mount the operating system’s file system and gain the ability to read or write any file. This has even more serious implications: For example, by overwriting a DLL library loaded by a different application, the attacker could execute malicious code on the system.
However, mounting the OS filesystem administrator works only on Windows, as attempting this on macOS would prompt the user for permission. Also on macOS Docker doesn’t run with administrator privileges like it does on Windows.
Although the impact is therefore not as critical on macOS, attackers can still modify and create new containers via the exposed TCP socket. On Linux, Docker doesn’t use TCP to manage its Engine API, instead using a named pipe that containers don’t have access to. As a result, Linux deployments are not impacted by the flaw.
While gaining access to a Docker container on a vulnerable installation is technically a requirement for exploiting this vulnerability, attackers could remotely proxy the malicious request through a web application running inside such a container.
“This is a high-risk scenario for those running Docker Desktop in an enterprise environment,” Gabrielle Hempel, security operations strategist at Exabeam told CSO. “This exploit is very attacker-friendly (read: easy to execute) and it’s the type of issue where the window of time between disclosure and patching is critical.”
Hempel added: “The bottom line is that container engines are increasingly treated as ‘just dev tooling,’ when in reality they carry the same risk surface as any privileged virtualization layer. This type of attack could easily be chained into a bigger supply chain compromise.”
No Responses