The vulnerability identified as CVE-2025-9074 affects Docker Desktop versions prior to 4.44.3 on Windows and macOS platforms. It arises from a security misconfiguration where the Docker Engine API is exposed on TCP port 2375 without TLS authentication if the user enables the 'Expose daemon on tcp://localhost:2375 without TLS' option. This API exposure allows unauthenticated local or remote attackers with network access to the port to fully control the Docker daemon. The exploit works by sending crafted API requests to the Docker daemon to create and start a container that uses bind mounts to map sensitive host filesystem directories into the container. This grants the attacker arbitrary access to host files and enables high-privilege remote code execution. The proof-of-concept exploit code, written in Perl, automates checking API availability, pulling container images, creating malicious containers with host bind mounts, and starting them to gain host access. The vulnerability is critical because it bypasses authentication entirely and leverages Docker’s powerful container management capabilities to compromise the host system. The exposure typically results from user-enabled settings intended for local testing but left enabled in production or network-exposed environments. The lack of TLS and authentication on the Docker API port 2375 is the root cause. Mitigation requires disabling this unauthenticated API exposure, enforcing TLS certificates for remote API access, and restricting network access to port 2375 via firewall rules. No official patch links are provided, but upgrading Docker Desktop beyond 4.44.3 is implied. The exploit does not require user interaction beyond network access and is effective against both Windows and macOS Docker Desktop installations.

For European organizations, this vulnerability poses a significant risk especially in environments where Docker Desktop is used for development, testing, or production container management on Windows or macOS endpoints. If the Docker daemon API is exposed without TLS and authentication, attackers can remotely execute arbitrary code with high privileges on affected hosts. This can lead to full host compromise, data theft, lateral movement within corporate networks, and disruption of containerized services. Organizations with lax network segmentation or exposed developer workstations are particularly vulnerable. The impact extends to confidentiality, integrity, and availability of systems and data. Given Docker Desktop's widespread adoption in European enterprises for containerized application development, the threat could affect a broad range of sectors including finance, manufacturing, and technology. The ability to remotely control the Docker daemon without authentication increases the attack surface and potential for supply chain or insider threat exploitation. The lack of known exploits in the wild currently reduces immediate risk, but the public availability of exploit code increases the likelihood of future attacks. The vulnerability also undermines trust in container security practices if left unmitigated.

1. Immediately disable the 'Expose daemon on tcp://localhost:2375 without TLS' option in Docker Desktop settings unless strictly required for isolated testing. 2. If remote Docker API access is necessary, enforce TLS authentication using properly configured certificates to secure communications. 3. Restrict network access to TCP port 2375 using firewall rules or network segmentation to ensure only trusted hosts can connect. 4. Upgrade Docker Desktop to version 4.44.3 or later, which addresses this vulnerability. 5. Audit existing Docker Desktop installations across the organization to identify any instances with exposed unauthenticated Docker APIs. 6. Implement endpoint detection and response (EDR) monitoring for suspicious Docker API activity or unexpected container creation. 7. Educate developers and IT staff about the risks of enabling unauthenticated Docker API exposure and enforce secure configuration baselines. 8. Regularly review and update container security policies to prevent misuse of bind mounts that expose sensitive host directories. 9. Use network-level controls such as VPNs or zero-trust architectures to limit access to Docker management interfaces. 10. Monitor threat intelligence feeds for updates on exploitation attempts and emerging mitigation techniques.