By rssfeeds-admin 
The vulnerability, designated CVE-2025-9074 and carrying a CVSS 4.0 score of 9.3 (Critical), was patched in Docker Desktop version 4.44.3 released on August 20, 2025.
The vulnerability affected Docker Desktop versions prior to 4.44.3 and allowed local Linux containers to access the Docker Engine API via the configured Docker subnet at 192.168.65.7:2375 by default, completely bypassing authentication mechanisms.
Security researcher who discovered the vulnerability noted that the issue occurred regardless of security configuration settings, including whether Enhanced Container Isolation (ECI) was enabled or the “Expose daemon on tcp://localhost:2375 without TLS” option was configured.
Windows Docker Desktop Vulnerability
The vulnerability’s exploitation required remarkably minimal effort, with attackers needing only two HTTP POST requests from within any container to achieve full host compromise.
The attack vector was so straightforward that it could be executed through Server-Side Request Forgery (SSRF) attacks without requiring direct code execution capabilities within the container.
The proof-of-concept exploit demonstrated how attackers could create a privileged container that mounted the host’s C: drive to a directory within the container, effectively granting complete access to the Windows host filesystem.
The entire attack sequence involved posting a JSON payload to /containers/create to bind the host drive, followed by a POST request to /containers/{id}/start to execute the malicious container.
What made this vulnerability particularly dangerous was its ability to work from any container environment.
As the researcher explained, “a SSRF or a simple web request from any container was enough to full compromise the host”.
This meant that even containers with minimal privileges could escalate to complete system control through the exposed Docker API endpoint.
Critical Infrastructure Impact
The vulnerability posed severe risks to organizations using Docker Desktop for Windows, particularly those running WSL backend configurations.
In these environments, successful exploitation allowed attackers to mount host drives with the same privileges as the user running Docker Desktop, potentially exposing sensitive corporate data and credentials.
Docker responded promptly to address the security gap, with the company acknowledging that “Enhanced Container Isolation (ECI) does not mitigate this vulnerability”.
The fix was included in Docker Desktop 4.44.3, released as part of Docker’s ongoing security update cycle.
The company’s security advisory emphasized the critical nature of the vulnerability, stating that “malicious containers running on Docker Desktop could access the Docker Engine and launch additional containers without requiring the Docker socket to be mounted”.
The vulnerability discovery highlighted fundamental assumptions about container isolation that proved incorrect.
The researcher noted finding the issue “by mistake” while conducting network scans of Docker’s documented private network ranges, emphasizing that “internal interfaces are not inherently secure” and calling for comprehensive testing of network isolation assumptions.
This incident serves as a stark reminder that unauthenticated APIs represent critical security risks regardless of their perceived internal network location, reinforcing the need for zero-trust security principles even within containerized environments.
Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.
The post Critical Windows Docker Desktop Vulnerability Enables Full Host Takeover appeared first on Cyber Security News.
Discover more from RSS Feeds Cloud
Subscribe to get the latest posts sent to your email.