CVE feed → CVE-2024-21626

CVE-2024-21626 — runc "Leaky Vessels" container breakout

A leaked internal file descriptor in runc — the container runtime under Docker, containerd, Podman, Kubernetes and Proxmox LXC — survived the chroot into the container and let a malicious image walk straight onto the host filesystem as root. One docker run on the wrong image was enough.

TL;DR

• Disclosed 2024-01-31 by Snyk Security Labs (Rory McNamara) as part of the "Leaky Vessels" cluster of container-runtime CVEs.
• Affects runc 1.1.11 and earlier — fixed in runc 1.1.12.
• Effective impact: a hostile container image (or an entrypoint in a pulled image) escapes the container and runs as root on the host.
• Not exploitable from inside an already-running unprivileged container — the bug needs the runtime to start a hostile workload. The threat model is "you ran something you shouldn't have."
• Fix landed quickly across Debian 12, Ubuntu 22.04 / 24.04, Proxmox VE 8.x, and the major container distributions in February 2024.
• Companion CVEs in BuildKit disclosed the same day: CVE-2024-23651, CVE-2024-23652, CVE-2024-23653.

At a glance

What "Leaky Vessels" actually means

When runc sets up a new container, it opens several internal file descriptors against host paths (/sys/fs/cgroup and friends) so it can apply cgroup limits, mount the rootfs, and pivot into the container. Those descriptors should never be visible to the workload that eventually executes inside the container.

In runc 1.1.11 and earlier, one of those internal descriptors leaked. It stayed open across the pivot into the new rootfs and was inherited by the container's first process. Because /proc/self/fd/N resolves through the open file table — not the current chroot — a process inside the container could use the leaked descriptor's /proc/self/fd/N path as a working directory and arrive in a host-side directory that the chroot was supposed to hide. From there, regular path operations relative to that working directory walked the host filesystem.

Because OCI image manifests get to choose the working directory and entrypoint, the entire chain can be encoded into the image itself: pull a malicious image, run it once, and the host is touched as root before any user code from inside the container ever runs. Snyk's disclosure includes a proof of concept; we deliberately don't reproduce the primitive here.

Affected runtimes and fix versions

runc ships either as a standalone binary (runc), bundled inside docker / containerd / podman packages, or vendored by Proxmox VE's pve-container for LXC management. The fix landed across all three packaging models in late January / early February 2024.

If your distro isn't in the table, check its security tracker for advisories matching CVE-2024-21626. Versions will vary, but every actively-maintained Linux distro published a fix within the first two weeks.

Quick scan check

Run any of these on a host to read the installed runc version. If the version is < 1.1.12 and your distro's security tracker hasn't backported the fix yet, the host is vulnerable.

# Standalone runc binary
runc --version

# What Docker is using
docker info | grep -A2 Runtimes
docker info | grep -i 'runc version' 2>/dev/null

# Debian / Ubuntu
apt list --installed 2>/dev/null | grep -E '^(runc|containerd|docker)'
dpkg -s runc 2>/dev/null | grep ^Version

# RHEL family
rpm -q runc containerd.io docker-ce 2>/dev/null

# Proxmox VE
pveversion -v | grep -E 'pve-container|lxc-pve|runc'

# containerd standalone
containerd --version

A clean homelab box should report runc version 1.1.12 or higher, with the distro packaging string also indicating a post-disclosure rebuild. Anything earlier needs an apt-get upgrade / dnf upgrade / pveupdate && pveupgrade cycle.

What Noxen does about this

Noxen's package-inventory probe enumerates runc, containerd, and Docker / Podman package versions on every enrolled Linux host over SSH and matches them against the signed daily CVE feed. A host running a vulnerable runc shows up as a high-severity finding with the recommended fix version and a link back to this page. The matcher is distro-aware — backported package strings like 1.1.5+ds1-1+deb12u1 are credited correctly against the upstream-aligned advisory.

The deep-dive

For the full narrative — what runc actually does, why homelab Proxmox users are over-exposed compared to enterprises, whether unprivileged LXC saves you (mostly yes), and the broader supply-chain pattern this CVE sits inside — read Container breakout in homelab Proxmox — CVE-2024-21626 explained on the Noxen blog.

Authoritative sources

• NVD entry for CVE-2024-21626
• cve.org record
• GHSA-xr7r-f8xq-vfvv — upstream runc advisory
• Snyk Security Labs — "Leaky Vessels" disclosure
• CISA KEV catalogue (search for CVE-2024-21626)

See what Noxen does about CVEs like this →   More on CVE management →