Docker: Part 4 — Escaping Docker Containers

Most of the time, Docker containers are designed to be isolated from the host system. But isolation isn’t security — and containers aren’t real sandboxes. Under certain conditions, it’s possible to break out of a container and compromise the host.

This post covers:

Real techniques for escaping Docker containers
Common misconfigurations that make breakouts possible
Real-world CVEs and exploitation paths
Step-by-step container escape scenarios

What Makes Escapes Possible?

Containers share the host kernel. That’s the key.

If a container is:

Running with --privileged
Mounted with sensitive directories (like /proc, /sys, or /dev)
Assigned dangerous Linux capabilities
Then that container is no longer properly isolated — and an attacker inside can escalate.

Method 1: `chroot` Into a Mounted Host Directory

If you’re inside a container that has access to the host’s root directory (for example, it’s mounted at /host), you can escape using chroot.

Step 1: Check for host mounts

mount | grep /host
ls /host

Step 2: Chroot into the host

chroot /host bash

You’re now inside the host filesystem, executing as root.

Step 3: Confirm

ps -eaf
id

You’ll see host processes and confirm you’re no longer isolated.

Method 2: Escape via CVE-2019-5736 (`runc` Vulnerability)

This is a container breakout that affects the underlying container runtime (runc). It allows an attacker to overwrite the runc binary and escape to the host.

Requirements:

The container must be started with root privileges
You must have write access inside /proc/self/exe

Exploitation flow (simplified):

Overwrite /proc/self/exe with a malicious binary
Wait for a container exec (e.g., docker exec)
Payload executes on the host with root privileges

This is a serious real-world escape. Many systems have patched it, but legacy infrastructure may still be vulnerable.

Method 3: Abuse `--privileged` Containers

A container started with --privileged can do almost anything on the host.

Step 1: Confirm privileged mode

docker inspect <container_id> | grep -i privileged

Step 2: Interact with host devices

ls /dev

Try interacting with:

/dev/kmsg (write kernel logs)
/dev/mem (raw memory access)
/dev/sda (raw disk)

This can allow for:

Kernel exploits
Memory dumps
Host system manipulation

Method 4: Leverage Extra Capabilities

Some containers are started with dangerous capabilities enabled.

Step 1: Check capabilities

capsh --print

If you see:

cap_sys_admin
cap_net_admin
cap_sys_ptrace
These are signs of trouble.

Step 2: Mount host filesystems

Try:

mkdir /mnt/host
mount -t ext4 /dev/sda1 /mnt/host

Or mount proc and sysfs:

mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys

With the right capabilities, you can mount sensitive host areas and escape or manipulate the environment.

Method 5: Dirty COW (CVE-2016-5195) and Kernel Exploits

If you have access to a vulnerable kernel inside the container, you may be able to escalate with a local kernel exploit.

uname -r

Check for old kernel versions. Use known exploits like:

Dirty COW
OverlayFS privilege escalation
Mempodipper

Since containers share the host kernel, exploiting it gives you host access.

Other Red Flags

Watch for the following when inside a container:

Mounted host directories like /, /proc, /sys, /root
Privileged container flags
Capabilities beyond the default set
Exposed /var/run/docker.sock inside the container

These are all signals that a container escape may be possible.

Summary

Escape Method	Requirement	Impact
`chroot` with host mount	Host FS is mounted	Full host access
CVE-2019-5736 (`runc`)	Writable `/proc/self/exe`	Remote root execution
`--privileged` container	Container started with full privileges	Access to host devices and kernel
Extra capabilities	Capabilities like `cap_sys_admin`	Mounting, privesc, host control
Kernel exploits	Vulnerable host kernel	Full compromise

Coming Up Next

In Part 5, we’ll walk through Real-World Docker Attack Scenarios — CI pipelines, developer environments, and production containers where misconfigurations can lead to full compromise. We’ll apply everything you’ve learned across realistic pentest situations.