A critical vulnerability identified as CVE-2025-9074 has been discovered in Docker Desktop for Windows and macOS, allowing a malicious container to compromise the host system—even when Enhanced Container Isolation (ECI) is active. The flaw, rated 9.3 in severity, is a server-side request forgery (SSRF) that permits unauthorized access to the Docker Engine API from within a running container.
Security researcher Felix Boulet uncovered that the Docker Engine API was accessible without authentication at http://192.168.65.7:2375/, making it possible to programmatically launch new containers. In his proof-of-concept (PoC), Boulet demonstrated using two wget HTTP POST requests to start a new container that binds the Windows host’s C: drive to its file system—allowing for unauthorized file access and potential privilege escalation.
While the issue affects both Windows and macOS, the risk is significantly higher on Windows. Philippe Dugre, a DevSecOps engineer, confirmed that Docker’s use of WSL2 on Windows allows attackers to mount the entire filesystem, read sensitive files, and even overwrite system DLLs to gain administrator privileges. On macOS, system safeguards such as user permission prompts and limited Docker privileges reduce the exploit’s impact, though Dugre warned that config tampering and backdooring risks remain.
Docker’s security bulletin notes that ECI does not mitigate this vulnerability, exposing even hardened environments to abuse. Despite differences in impact across platforms, the vulnerability underscores a serious lapse in container boundary enforcement and access control.
Healthcare IT environments that leverage Docker Desktop for application development, data processing, or containerized services should immediately assess exposure to CVE-2025-9074. These environments often involve regulated data and legacy systems, making host compromise a critical risk. Organizations should:
- Stop using Docker Desktop on Windows for sensitive workloads until patched versions are available.
- Restrict access to the Docker Engine API using firewall rules or interface binding configurations.
- Regularly review container capabilities and ensure least privilege configurations.
- Consider shifting to Linux-based Docker hosts, which were not affected by this specific flaw.
In clinical and research settings where Docker is used for AI/ML workloads or diagnostics, treat any container that touches PHI as untrusted unless proven otherwise. Revisit segmentation strategies and deploy runtime protection tools to monitor container behavior in real time.
