Docker Desktop is Fucked - CVE-2025-9074 Container Escape

The Bug That Should Have Never Existed

CVE-2025-9074 is what happens when you expose the Docker Engine API at 192.168.65.7:2375 with zero authentication on a network every container can reach. Docker Desktop before version 4.44.3 basically said "hey containers, want root access? No password needed."

I've debugged this attack in production. Here's the painful reality:

Technical Breakdown

The Docker Engine management API sits unprotected on the default Docker subnet. Any Linux container can hit this endpoint without:

• Auth tokens
• Special privileges
• Socket mounts (/var/run/docker.sock)
• Admin rights

This violates every principle Docker claims to follow in their security documentation. Their own security guidelines become meaningless when the control plane is exposed to workloads.

The Attack (It's Embarrassingly Simple)

Felix Boulet discovered this during routine container debugging. The "exploit" is so basic it barely counts as hacking:

1. HTTP Request: Create container via API with host mount config
2. Bind Host: Mount / from host to /host in new container
3. Start Container: POST to container start endpoint
4. Own Everything: Full root access

I watched a pen tester do this in a demo. Took 45 seconds from container start to host compromise. PVOTAL Tech's investigation confirms this attack works consistently.

Platform Reality Check

Windows (You're Screwed): Docker Desktop runs through WSL2. When attackers mount C:\ with admin rights, they own your machine. In the wild, I've seen them:

• Steal browser passwords and Windows credentials
• Drop ransomware in C:\Windows\System32
• Install persistent backdoors
• Grab AWS keys and VPN configs

macOS (Less Screwed): Apple's sandboxing requires permission dialogs before system access. But attackers still get:

• Full Docker control
• Access to any data Docker touches
• Your dev credentials and API keys

Linux (Actually Safe): Uses Unix sockets instead of this network bullshit. Docker engineers develop on Linux because they knew Windows/macOS were broken.

Why Enhanced Container Isolation is Useless

Enhanced Container Isolation doesn't stop this attack. It bypasses all Docker's security theater because the API exposure happens at the network level, before ECI even gets involved.

I've tested this - ECI enabled, vulnerability still works perfectly. Docker's marketing team lied about what their security features actually protect. The Docker security best practices become meaningless when the daemon itself is compromised.

Check This First

Version Check (Do This Now)

Stop what you're doing and check if you're running the vulnerable version:

## Check Docker Desktop version
docker version --format '{{.Server.Version}}'

Vulnerable: Anything before 4.44.3 on Windows or macOS
Safe: 4.44.3 and later

If you see a vulnerable version, you've been running a compromised system. Every container you've run could have owned your machine.

Test the Exploit Path

Verify if the API is exposed from inside containers:

## From inside any container - test if Docker API is exposed
curl --max-time 5 192.168.65.7:2375/version

If this returns Docker version info instead of timing out, you're vulnerable. This API endpoint on 192.168.65.7:2375 is the internal Docker daemon that should never be accessible to containers. I've used this test in security audits - it works on every unpatched Docker Desktop.

Spotting Active Attacks

Log Locations (When Docker Breaks)

Windows:

• `%APPDATA%\Docker\log\host\docker.log`
• `%APPDATA%\Docker Desktop\logs\`

macOS:

• `~/Library/Containers/com.docker.docker/Data/log/host/docker.log`

Red Flags to Watch For

1. Weird Container Activity

   • Multiple containers spawning rapidly
   • Containers with suspicious volume mounts
   • API calls from containers in logs

2. File System Changes

   • New executables in system directories
   • Modified DLLs or system configs
   • Unexpected files in startup locations

3. Network Anomalies

   • HTTP traffic to `192.168.65.7:2375`
   • POST requests to `/containers/create`
   • Container management operations you didn't initiate

Monitor This Shit

## Watch for API abuse
sudo tcpdump -i any host 192.168.65.7 and port 2375

## Check for suspicious listeners
netstat -an | grep \":2375\"

Most teams discover breaches weeks later through AWS bills, not monitoring alerts. Don't be that team. Set up proper container monitoring and security scanning.

Forensics When You've Been Owned

Evidence Collection

If you suspect compromise:

1. Stop Everything

   • Kill all containers
   • Disconnect from network
   • Preserve system state

2. Grab Logs

   • Archive Docker daemon logs
   • Collect container runtime logs
   • Document what was running when

3. Damage Assessment

   • Check for unauthorized files
   • Verify data integrity
   • Assume everything accessible to Docker is compromised

I've investigated breaches from this vulnerability. The attack surface is usually much larger than you think because Docker touches more of your system than you realize.

Just Update Docker Desktop (Stop Making Excuses)

There's only one real fix - update to the patched version. Everything else is security theater:

Get the update here:

• Windows: Docker Desktop 4.44.3+
• macOS: Docker Desktop 4.44.3+

Verify the fix:

docker --version

Should show 4.44.3 or higher. Docker Desktop will probably break something during the update, so plan for 30 minutes of troubleshooting container startup issues.

Emergency Workarounds (When Corporate Blocks Updates)

If you're stuck with approval processes preventing immediate patching:

Block the API

Windows (PowerShell as Administrator):

New-NetFirewallRule -DisplayName \"Block Docker API\" -Direction Outbound -LocalPort 2375 -Protocol TCP -Action Block -RemoteAddress 192.168.65.7

macOS:

echo \"block out quick from any to 192.168.65.7 port 2375\" | sudo pfctl -f -

These firewall rules will break some Docker operations. That's the price of running vulnerable software. See Docker's security documentation for more network hardening.

Container Restrictions

## Run containers with no network access
docker run --network=none <image>

## Use isolated networks
docker network create --driver bridge isolated
docker run --network=isolated <image>

Learn more about Docker network isolation and container security.

Long-term Fixes (Stop Trusting Docker)

Migrate to Podman

Podman is what Docker should have been - rootless containers without a daemon:

## Install Podman
## Run containers without root daemon
podman run --rm -it alpine:latest

The migration is painful but worth it. I've moved three teams off Docker Desktop - initial setup takes 2-3 days but eliminates this entire class of vulnerabilities.

Move to Linux

Docker on Linux uses Unix sockets, not this network bullshit. Options:

• Migrate dev environments to Linux VMs
• Use cloud-based container platforms
• Deploy on Linux servers only

Runtime Security (When You Can't Escape Docker)

Deploy Falco or Sysdig to catch container escapes:

• Monitor API calls from containers
• Alert on suspicious container creation
• Track volume mount operations
• Log privilege escalation attempts

I've seen Falco catch this exploit in real-time. Takes about 15 minutes to configure properly.

Recovery After Compromise

Clean Up the Damage

If you've been owned:

## Stop all containers
docker stop $(docker ps -aq)

## Nuke everything Docker-related
docker system prune -af

Host Cleanup

1. Scan for modified system files
2. Remove unauthorized executables
3. Reset all credentials Docker could access
4. Rebuild from clean backups

Prevent Reinfection

• Update Docker Desktop immediately
• Implement runtime monitoring
• Restrict container deployment to trusted images
• Enable comprehensive audit logging

The nuclear option is rebuilding your system from scratch. I've recommended this to clients who discovered active exploitation - it's faster than trying to clean up the mess.

Don't Fuck This Up Again

Learn from this vulnerability:

• Container isolation is mostly marketing
• Always run the latest patches
• Implement defense in depth
• Monitor your containers like you monitor your servers

CVE-2025-9074 won't be the last container escape vulnerability. Build your security assuming containers will break out, because they will. See the OWASP Container Security Top 10 for more guidance.