Docker container escape

The phrase “container escape” suggests an exploit. In practice, most escapes are configuration — the container was handed the means to leave before anyone attacked it.

Worth being precise about, because it changes what you defend against. There are two categories and they need different responses.

Category one: it was never a boundary

These need no vulnerability. Each is documented behaviour.

The socket. A container with /var/run/docker.sock mounted can ask the daemon — which is root — to start another container with / mounted:

# from inside the container that has the socket
docker run -v /:/host --privileged -it alpine chroot /host sh

That’s host root. The “escape” is an API call.

--privileged. No capability restrictions, no seccomp, no AppArmor, and host devices visible. The container mounts the host’s disk and writes to it:

fdisk -l && mount /dev/sda1 /mnt && echo key >> /mnt/root/.ssh/authorized_keys

The docker group. Same as the socket, from a shell instead of a container. Membership is root.

Host namespaces. --pid=host lets a container see and signal host processes; --net=host puts it on the host’s network stack, past your firewall rules.

None of these are bugs. They are why the pages on the socket and privileged mode sit at the top of this cluster — patching cannot help you here, and no CVE will ever be filed.

Category two: actual vulnerabilities

These are real bugs, and they are why runc matters as much as docker.

Leaky Vessels (January 2024) — a set of four:

CVE	Component	Effect
CVE-2024-21626	runc	File descriptor leak → access to the host filesystem
CVE-2024-23651	BuildKit	Race condition → container breakout
CVE-2024-23652	BuildKit	Arbitrary file deletion on the host during build
CVE-2024-23653	BuildKit	Breakout during image build

Fixed in runc 1.1.12 and BuildKit v0.12.5.

The point isn’t these specific CVEs — they’re patched everywhere by now. It’s where they lived: runc is the thing that actually creates containers, and a current Docker with a stale runc is a current Docker with an escape. Two of the four were in the build path, which means a hostile Dockerfile — from a dependency, a fork, a PR — was enough. If you build untrusted images in CI, BuildKit is part of your attack surface.

Check runc separately. Nothing about docker version tells you it’s current.

Verify it worked

Find the handed-away boundaries first — this is where the escapes are:

# Containers with the socket mounted = root on the host
docker ps -q | xargs -r docker inspect \
  --format '{{.Name}}: {{range .Mounts}}{{.Source}} {{end}}' | grep docker.sock

# Privileged containers
docker ps -q | xargs -r docker inspect \
  --format '{{.Name}} privileged={{.HostConfig.Privileged}}' | grep -v false

# Host namespace sharing
docker ps -q | xargs -r docker inspect \
  --format '{{.Name}} pid={{.HostConfig.PidMode}} net={{.HostConfig.NetworkMode}} ipc={{.HostConfig.IpcMode}}' \
  | grep -E 'pid=host|net=host|ipc=host'

# Who has root via the group
getent group docker

Every line of output is a boundary you don’t have.

Then check the patch level:

docker version --format '{{.Server.Version}}'
runc --version
docker buildx version

runc must be 1.1.12 or later. Compare against your distro’s current package rather than assuming:

apt list --upgradable 2>/dev/null | grep -E 'runc|containerd|docker'

Were you escaped? Look for what an escape leaves on the host:

sudo ls -lat /root/.ssh/ 2>/dev/null
sudo crontab -l 2>/dev/null; sudo ls -lat /etc/cron.d/
docker ps -a --format '{{.Names}}\t{{.Image}}\t{{.Command}}' | grep -iE 'chroot|/host|nsenter'

A container in your history that mounted / and ran chroot is not ambiguous.

Before you apply this

If a container with the socket or --privileged was compromised, the host is compromised. Not “may have been” — the container had, by design, the ability to become root. Removing the mount afterwards changes nothing about what already happened.

Response:

1. Isolate the host from the network. Don’t restart Docker — that clears docker ps state and running-process evidence.
2. Enumerate what the container could reach: the socket (all of it), --privileged (all of it), a bind mount (that path), --net=host (your internal network past the firewall).
3. Check for persistence — authorized_keys, cron, systemd units, and new images or containers in docker images / docker ps -a.
4. Rebuild the host. A root-capable escape means you cannot enumerate what was left. Rebuild, and rotate every credential the host held — registry tokens, cloud metadata credentials, deploy keys, everything in the containers’ environment variables.

Cloud metadata is the specific thing people forget. A container with --net=host, or often just default networking, can reach 169.254.169.254 and retrieve the instance’s IAM credentials. The escape may have ended in your cloud account rather than on the host. Check that role’s activity in your audit log, not just this machine.

Going forward, the ordering that actually prevents this: socket → privileged → rootless. The first two remove the handed-away boundaries; the third means the next runc CVE lands as an unprivileged user instead of root.

Related

• Hardening Docker — the full checklist.
• Protect the Docker socket — the one that matters most.