Versions of Docker Desktop before 4.44.3 (released on 20 August 2025) had a serious vulnerability that could enable an attacker to use Linux containers to bypass security and directly access the Docker engine API without an authentication mechanism, thus enabling unauthorized access to a host as though it were an actual Linux installation. This vulnerability is assigned CVE-2025-9074 and has a Common Vulnerability Scoring System (CVSS) score of 9.3 (Critical).
This situation arises as a result of the internal configuration where the Docker daemon's HTTP API endpoint at 192.168.65.7:2375 within the Docker subnet was configured so that there were no authentication or access control mechanisms in place to prevent unauthorized users from accessing this port. Consequently, an attacker can compromise a device with the Docker engine without the need for a user to authenticate with the host machine and bypass any security controls that may be installed and present an unlimited capability to access the host machine.
Any container on the same Docker Desktop instance could connect directly to this API, bypassing the need for the traditional /var/run/docker.sock mount or explicit TCP exposure settings. Enhanced Container Isolation (ECI) offered no protection here.
Exploitation was straightforward once inside a container: an attacker could use the API to create new privileged containers with host filesystem bind mounts (e.g., / → /host), read/write sensitive files, overwrite system DLLs (on Windows for LPE), or execute arbitrary commands. On Windows, this often led to full administrator takeover; on macOS, impact was somewhat limited by additional permission prompts but still allowed significant manipulation.
The vulnerability was not present in native Docker on Linux (different socket mechanics). The only operating systems that were affected were Windows and macOS (one of whom needs to exploit a vulnerability inside containers via either an exploited image or through supply-chain method). On the container level, version 4.44.3 fixes the issue by limiting access to internal APIs, as well as enforcing proper isolation.
Public proof of concept code began appearing shortly after the vulnerability was disclosed in August 2025 (and included variants on both Github and Exploit-DB) and demonstrated both read only checks and complete escapes. In addition to these types of PoC, some targeted the default subnet IP that the API uses for requests, while others automated the creation of malicious containers.
Timetable of Key Events
1. August 2024 : Discovery of SSRF-like bypass (by researcher Philippe Dugre of pvotal.tech).
2. August 20, 2024 : Patch for Docker Desktop issued (version 4.44.3).
3. Public proof-of-concept exploits became available by end August/beginning September 2024, including the one shared (attributed to OilSeller2001, dated October 6 2024; likely representing a newer variation or another example of an exploit).
4. No significant evidence of exploits at this time; however, with public proofs-of-concept available to assist early-stage attackers with access to initial containers, it would be easy to take advantage of containerized applications' vulnerabilities.
Mitigation
1. Update Docker Desktop to 4.44.3 or later (current stable is well beyond this).
2. Only enable "Expose daemon on TCP://localhost:2375 without using TLS" when required, but even then do so with an aggressive firewall.
3. Only use trusted/signed image files; never run untrusted images in the container with elevated privileges, i.e., root.
4. Use security compliance tools (falco and Sysdig) to monitor for unusual docker API requests or privileged mount activity.
5. On Windows/macOS, treat Docker Desktop as a high-risk dev tool, consider isolated VMs for untrusted workloads.
The PoC is a classic demonstration script: it assumes the API is reachable (often via the internal subnet from inside a container), pulls an image, spins up a new one with host mounts, and starts it. Running it against an unpatched setup would indeed grant host-level access, hence the severity.
This one is a textbook example of how a seemingly small network config oversight in container tooling can cascade into full host compromise. Always patch fast, and never expose management APIs without strong auth.
Source: Exploit DB
