CVE-2025-9074: Docker Desktop Privilege Escalation Flaw

CVE-2025-9074 Overview

A critical vulnerability has been identified in Docker Desktop that allows local running Linux containers to access the Docker Engine API via the configured Docker subnet at 192.168.65.7:2375 by default. This exposure occurs regardless of whether Enhanced Container Isolation (ECI) is enabled and persists even when the "Expose daemon on tcp://localhost:2375 without TLS" option is disabled.

This vulnerability enables attackers to execute a wide range of privileged commands to the engine API, including controlling other containers, creating new ones, and managing images. On Docker Desktop for Windows with the WSL backend, the vulnerability additionally allows mounting the host drive with the same privileges as the user running Docker Desktop, potentially leading to complete host compromise.

Critical Impact

Attackers operating from within a container can escape isolation to gain full control over the Docker environment and potentially compromise the underlying host system, including access to sensitive files and the ability to launch arbitrary containers.

Affected Products

• Docker Desktop (all platforms)
• Docker Desktop for Windows with WSL backend
• Docker Desktop for Mac

Discovery Timeline

• 2025-08-20 - CVE-2025-9074 published to NVD
• 2025-09-25 - Last updated in NVD database

Technical Details for CVE-2025-9074

Vulnerability Analysis

This vulnerability represents a significant container isolation bypass in Docker Desktop. The fundamental issue stems from improper exposure of the Docker Engine API endpoint to containers running on the internal Docker network subnet. By design, containers should be isolated from the Docker management plane, but this vulnerability creates an unintended communication path that breaks this isolation boundary.

The vulnerability is classified under CWE-668 (Exposure of Resource to Wrong Sphere), which accurately describes how the Docker Engine API—a highly privileged interface intended only for administrative access—becomes accessible to untrusted container workloads. The attack surface is particularly concerning because it bypasses security controls that administrators typically rely upon, including Enhanced Container Isolation.

Root Cause

The root cause lies in the network configuration of Docker Desktop's internal architecture. The Docker Engine API is inadvertently bound to an interface accessible from the container network subnet (192.168.65.0/24 by default). This binding persists across multiple security configurations, indicating a fundamental design issue in how the API endpoint is exposed within the Docker Desktop networking stack.

The exposure occurs at 192.168.65.7:2375, which is reachable from any container running on the default Docker bridge network. This configuration error allows containers to communicate with the Docker daemon as if they were a privileged management client.

Attack Vector

An attacker with the ability to execute code within a container can exploit this vulnerability through the following attack pattern:

1. From within a compromised or malicious container, the attacker identifies the Docker Engine API endpoint on the internal subnet
2. The attacker sends unauthenticated API requests to 192.168.65.7:2375
3. Using the Docker API, the attacker can enumerate running containers, create new privileged containers, or mount host filesystems
4. On Windows with WSL backend, the attacker can mount the host drive (typically C:) with user-level privileges

The attack requires no authentication as the API endpoint lacks TLS or credential verification in this exposure scenario. Technical details about the exploitation methodology can be found in the Pivotal CVE-2025-9074 Analysis and the QwertySecurity Blog Post.

Detection Methods for CVE-2025-9074

Indicators of Compromise

• Unexpected network connections from containers to 192.168.65.7:2375 on the Docker internal network
• Unusual Docker API activity patterns, particularly container creation or volume mount operations originating from container IP addresses
• New containers spawned with privileged flags or host filesystem mounts that were not administratively authorized
• Container logs showing curl or HTTP client activity targeting the Docker subnet gateway addresses

Detection Strategies

• Monitor network traffic within the Docker internal subnet for connections to port 2375
• Implement audit logging for Docker Engine API calls and alert on API requests originating from container IP ranges
• Use container runtime security tools to detect unexpected network egress to internal Docker infrastructure addresses
• Deploy endpoint detection to identify containers attempting to access the Docker socket or API endpoints

Monitoring Recommendations

• Enable detailed Docker daemon logging with --log-level=debug to capture API access patterns
• Configure network monitoring on the Docker bridge interfaces to detect lateral movement attempts
• Implement SIEM rules to correlate Docker API events with container network activity
• Regularly audit running containers for unexpected privileged capabilities or host mounts

How to Mitigate CVE-2025-9074

Immediate Actions Required

• Update Docker Desktop to version 4.44.3 or later immediately
• Audit all currently running containers for signs of compromise or unauthorized configuration changes
• Review and validate any containers with privileged access or host filesystem mounts
• Implement network segmentation to restrict container access to internal Docker infrastructure

Patch Information

Docker has released a security update addressing this vulnerability. According to the Docker Release Notes, version 4.44.3 includes the fix for CVE-2025-9074. Organizations should prioritize upgrading to this version or later. Additional detection and mitigation guidance is available from Vicarius CVE-2025-9074 Mitigation.

Workarounds

• Restrict which containers are deployed and implement strict container image provenance controls until patching is complete
• Consider temporarily disabling Docker Desktop and using alternative containerization solutions for critical workloads
• Implement network policies using tools like Calico or Cilium to block container access to the Docker internal subnet
• Run containers with --network=none where network access is not required to eliminate the attack vector

# Configuration example
# Run containers without network access as a temporary mitigation
docker run --network=none --rm -it your-container:latest

# Verify Docker Desktop version
docker version --format '{{.Client.Version}}'

# List containers with privileged access for audit
docker ps --format '{{.Names}}' | xargs -I {} docker inspect {} --format '{{.Name}}: Privileged={{.HostConfig.Privileged}}'