If you're staring down a scanner report screaming CVE-2024-21626 and wondering whether you actually need to drop everything, here's the short version: yes, if you run untrusted images, patch today. The good news is the fix is a package update, not a rearchitecture.
The fix
Update runc to 1.1.12 or later. That's the only thing that actually closes the hole. Everything else is defense in depth.
On a typical Linux host with Docker:
sudo apt update
sudo apt install --only-upgrade runc
# or on RHEL/CentOS/Rocky:
sudo dnf update runcCheck what you actually have installed afterwards, because package managers lie about what's on disk when multiple copies exist:
runc --version
# should report: runc version 1.1.12
# commit: v1.1.12-0-g51d5e94
docker info | grep -i runcIf you're on Docker Desktop or a managed Docker Engine, upgrade the whole stack:
- Docker Engine 25.0.2 or later
- Docker Desktop 4.28.0 or later
- containerd 1.6.28, 1.7.13, or later (the fix is in the runc dependency, but bump containerd too)
On Kubernetes, the fix lands through your node OS image or the containerd/runc packages on the nodes. If you're on EKS, GKE, or AKS, check the vendor advisory — most published patched AMIs and node images within a week of the January 31, 2024 disclosure. For self-managed clusters, run the upgrade on every node and drain them one at a time:
kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data
# ssh in, upgrade runc + containerd, restart containerd
sudo systemctl restart containerd
kubectl uncordon node-1Stop any container built from an untrusted image, and rebuild anything you cached locally from a registry you don't control. The exploit works at container start time, so an image that ran before the patch could already have planted something.
Why this works
What's actually happening here is a file descriptor leak in runc's handling of WORKDIR. When runc sets up a container, it opens the working directory and passes the file descriptor through to the container process. In vulnerable versions, that descriptor pointed at the host's filesystem rather than the container's. If you craft a Dockerfile with a malicious WORKDIR instruction — or exploit a running container with docker exec — you can walk that descriptor into the host's /proc/self/fd, then chdir into the host's root.
The reason updating runc fixes it: runc 1.1.12 validates that the file descriptor points inside the container's mount namespace before handing it over. The leak is closed at the source. There's no config flag, no seccomp profile, no --privileged=false that fully compensates — the descriptor was already passed by the time your container policy kicks in.
The CVE was reported by Rory McNamara at Snyk, disclosed January 31, 2024, alongside three sibling bugs (CVE-2024-23651, -23652, -23653) in BuildKit and runc. They were nicknamed "Leaky Vessels" for the way data escapes the container.
Less common variations
Not every report of container escape maps cleanly to CVE-2024-21626. A few situations you'll bump into:
Old images pinned to specific runc versions
Some CI systems ship their own runc binary inside the runner image. apt upgrade on the host does nothing for those. Check which runc and ls -l $(which runc) — if it points into /usr/local/bin or a toolchain directory, you installed it by hand and need to replace it by hand.
BuildKit and buildx
CVE-2024-23651 and -23653 hit docker build, not docker run. If your threat model is "untrusted Dockerfile from a PR," you need BuildKit patched too. Update Docker Engine to 25.0.2+ and set:
export DOCKER_BUILDKIT=1
# buildx v0.12.1+ ships the fixRootless Docker and Podman
Rootless containers blunt the blast radius but don't fix CVE-2024-21626. A container escape from a rootless pod lands you in the user namespace, not the host root — still bad, but not catastrophic. Patch anyway.
Kubernetes with containerd shim v1
Shim v1 sometimes bundles its own runc path. Check /run/containerd/runc/. If there's a cached binary that predates 1.1.12, delete it and restart containerd — otherwise it'll keep using the stale copy even after you upgrade the system package.
Prevention
Patching is reactive. Here's what keeps you off the next advisory's vulnerable list:
- Pin your runc. Track the upstream
runcreleases page, not just your distro's security feed. Distros lag by days to weeks. - Run untrusted images in a sandbox that isn't runc. gVisor or Kata Containers put a real boundary between the container and the host kernel. For CI runners and multi-tenant build fleets, this is the real answer.
- Drop
CAP_SYS_ADMINand mount/procwithhidepid=2. Not a full fix, but it removes the easiest paths after an fd leak. - Scan images before they hit a build host. Trivy and Grype both flag CVE-2024-21626 in the runc layer. Wire them into CI, and block on criticals.
- Watch the exit path, not just the entry path. The classic Leaky Vessels abuse pattern is an
ENTRYPOINTthat runs a script doingcd /proc/self/fd/.... If a container ever touches/proc/self/fdunder a path it shouldn't, that's your alarm.
One more thing: after you patch, kill every running container. The exploit needs a fresh container start, but a container that started vulnerable and is still running is a container whose namespace setup you can't trust. docker restart is cheap. Do it.