Docker CVE-2025-9074: Critical Container Escape Vulnerability

Critical Vulnerability Details

CVE-2025-9074 - CVSS 9.3 Critical severity container escape vulnerability in Docker Desktop

Attack Vector

• Vulnerability Type: Server-Side Request Forgery (SSRF) exposing Docker Engine API
• Affected Endpoint: 192.168.65.7:2375 (Docker Engine API)
• Access Method: HTTP requests from any container to internal Docker API
• Bypass Capability: Works regardless of Enhanced Container Isolation (ECI) settings
• Network Path: Exploits Docker Desktop's internal networking configuration

Affected Systems

• Platforms: Windows and macOS Docker Desktop installations only
• Vulnerable Versions: All Docker Desktop versions before 4.44.3
• Linux Impact: Docker Engine on Linux is NOT affected
• Corporate Risk: Affects all installations regardless of security configurations

Attack Capabilities and Impact

What Attackers Gain

1. Full Docker Engine Control

   • Create/stop/delete any containers
   • Pull malicious images from external registries
   • Delete existing container images
   • Modify Docker networking configurations

2. Host System Access

   • Mount entire host filesystem with user privileges
   • Access to /mnt/c/ on Windows WSL2 backend
   • Windows user file access with Docker Desktop user privileges
   • Potential persistence via scheduled tasks or startup folders

Real-World Exploitation

# Example exploit payload (demonstrates attack vector)
curl -X POST http://192.168.65.7:2375/v1.43/containers/create \
  -H "Content-Type: application/json" \
  -d '{"Image":"alpine","HostConfig":{"Binds":["/:/hostfs:rw"]}}'

Result: Complete host filesystem mounted in attacker-controlled container

Emergency Patch Requirements

Immediate Actions (10-minute response window)

1. Version Check

   docker --version  # Must show Docker Desktop 4.44.3+
   

2. Emergency Update Process

   • Windows: Download from docker.com, run as administrator, restart required
   • macOS: Use Docker Desktop auto-updater or manual installer
   • Corporate: Push through deployment pipeline immediately (override normal testing)

3. Patch Verification

   # This connection MUST fail after patching
   docker run --rm alpine timeout 5 nc -v 192.168.65.7 2375
   # Expected: Connection refused or timeout
   # If successful: Still vulnerable, patch failed
   

Critical Configuration Issues

Settings That Don't Protect

• Enhanced Container Isolation: Vulnerability works despite ECI being enabled
• "Expose daemon on tcp://localhost:2375 without TLS" disabled: API still exposed via internal subnet
• Firewall rules: Internal Docker networking bypasses host firewall

Fix Implementation

• Docker 4.44.3: Completely removes network path to Engine API from containers
• Not access control: Eliminated the network route entirely (CWE-668 fix)
• Verification method: Connection test to 192.168.65.7:2375 must fail

Production Environment Response

Incident Detection

Log Analysis Locations:

• Windows: %USERPROFILE%\.docker\machine\machines\default\docker.log
• macOS: ~/Library/Containers/com.docker.docker/Data/log/

Compromise Indicators:

• Unusual container creation patterns in Docker daemon logs
• Volume mounts to host directories (/, /mnt/c/, /Users/)
• Image pulls from unknown/suspicious registries
• Network connections to 192.168.65.7:2375

Evidence Collection Commands

# Document container state before cleanup
docker ps -a --format "table {{.Names}}\t{{.Image}}\t{{.CreatedAt}}\t{{.Status}}" > containers_$(date +%Y%m%d).txt

# Capture suspicious mounts
docker inspect $(docker ps -aq) | jq '.[].HostConfig.Binds' > mounts_$(date +%Y%m%d).json

# Monitor for ongoing exploitation
ss -tuln | grep 2375

Risk Assessment and Business Impact

Severity Justification

• Public exploits available: Active exploitation techniques documented
• Zero-day to patch window: Vulnerability had widespread exposure before fix
• Corporate environment impact: All Windows/macOS development machines vulnerable
• CI/CD exposure: CI runners using Docker Desktop vulnerable

Business Continuity Decisions

• Patch override policy: Critical security updates override normal testing procedures
• Air-gapped environments: Higher risk due to limited monitoring capabilities
• Development workflow: Stop running untrusted containers until patched

Resource Requirements

Emergency Response Time Investment

• Immediate patching: 10-15 minutes per system
• Verification process: 5 minutes per system
• Incident investigation: 2-4 hours for comprehensive analysis
• Network monitoring setup: 1-2 hours for audit logging configuration

Expertise Requirements

• Patching: Basic Docker Desktop administration
• Verification: Command-line proficiency and network troubleshooting
• Incident response: Container security expertise and log analysis skills
• Long-term monitoring: Security operations and audit logging setup

Post-Patch Hardening

Mandatory Security Controls

1. Container Image Security

   export DOCKER_CONTENT_TRUST=1  # Enable image signature verification
   docker scout quickview <image_name>  # Scan before running
   

2. Registry Security

   • Use private registries with authentication
   • Implement image signing with Notary
   • Regular vulnerability scanning of base images
   • Avoid latest tags in production

3. Network Monitoring

   # Monitor Docker API access (macOS example)
   tail -f ~/Library/Containers/com.docker.docker/Data/log/vm/dockerd.log | grep -E "(POST|PUT|DELETE)"
   

Organizational Changes Required

• Incident response plan updates: Define emergency patch authorization
• Security training: Container security awareness including network isolation concepts
• Regular update cadence: Weekly Docker Desktop updates, not just critical CVE responses
• Registry compromise response: Procedures for suspicious image identification

Failure Scenarios and Recovery

Common Patch Failures

1. Docker Desktop didn't restart properly: Reboot machine completely
2. Updated CLI but not Desktop: Verify version in Docker Desktop GUI, not just CLI
3. Corporate proxy interference: May block connection tests, verify through alternative methods
4. Partial update application: Docker services may need manual restart

If Patching Fails

• Immediate isolation: Disconnect affected systems from network
• Container suspension: Stop all running containers until patch successful
• Manual installation: Download installer directly, clean install if necessary
• Escalation path: Contact Docker support for enterprise installations

Compromise Recovery

1. Nuclear option: docker system prune -a --volumes (removes all Docker data)
2. Selective cleanup: Remove suspicious containers and images individually
3. Forensic preservation: Capture container state before cleanup for investigation
4. Re-imaging consideration: For high-security environments, consider full system re-imaging

Long-term Monitoring and Prevention

Detection Systems

• Image scanning: Integrate Docker Scout or Trivy into CI/CD pipelines
• Runtime monitoring: Sysdig Falco or similar for container behavior analysis
• Network monitoring: Alert on containers connecting to management interfaces
• Registry monitoring: Track image pulls from unknown sources

Compliance and Standards

• CIS Docker Benchmark: Implement security configuration guidelines
• NIST Container Security Guide: Government-standard container security practices
• Regular audits: Quarterly container security assessments
• Incident response testing: Annual tabletop exercises for container compromise scenarios

Technical Debt and Architecture Lessons

• Container isolation assumptions: Network isolation is as critical as process/filesystem isolation
• "Internal" network security: Internal networks require the same security controls as external
• Management API exposure: Any API accessible from containers presents attack surface
• Security model validation: Regular penetration testing of container isolation boundaries