Leaky Vessels (CVE-2024-21626): Container Escape Risk for Docker on Proxmox

"Leaky Vessels" was one of the more widely felt container security stories of early 2024, and if you run Docker anywhere on your Proxmox box, it applies to you. The headline bug, CVE-2024-21626, is a container escape in runc — the low-level runtime that Docker, containerd and Kubernetes all use to actually start containers. It carries a CVSS 3.1 score of 8.6 (High).

The full metadata and scoring are on the CVE-2024-21626 entry on CVE Explore.

How the escape works

The flaw is a file descriptor leak in runc. Under specific conditions, an internal file descriptor referencing the host filesystem is left open and inherited by the container process. With a crafted image or container configuration — for example, abusing the WORKDIR instruction to resolve a path through that leaked descriptor — a process inside the container ends up operating in the host's filesystem namespace instead of the container's.

From there an attacker can read host files or, worse, overwrite host binaries to achieve a complete breakout from container to host. The exploitation requires user interaction (building or running a malicious image), which is reflected in the CVSS vector, but the impact is full host compromise.

Why this matters on Proxmox specifically

A lot of Proxmox homelabs don't stop at VMs and LXCs — they run Docker workloads too, in one of two common patterns:

• Docker inside a VM on Proxmox — the standard, well-isolated approach.
• Docker nested inside a Proxmox LXC — popular for density, and the subject of plenty of homelab guides.

In both cases the container engine ships runc, so both are exposed to CVE-2024-21626. The important nuance: Proxmox's native containers use liblxc, not runc, so a plain LXC without Docker is not directly affected by this particular CVE. The risk arrives the moment you install Docker (or another OCI runtime) on the host, in a VM, or in a container.

This is exactly why nesting trust boundaries matters: a Docker breakout inside an LXC can land you on the LXC's root, and a privileged LXC shares a lot with the Proxmox host.

Checking and patching

Find out which runtime version you are on:

# Inside the VM/LXC (or host) running Docker
docker version
runc --version

If runc is below 1.1.12, update it. On Debian/Ubuntu-based systems that means pulling the patched Docker/containerd packages:

apt update
apt install --only-upgrade docker-ce docker-ce-cli containerd.io
# or, if runc is packaged standalone:
apt install --only-upgrade runc

Then recreate your containers so they run under the patched runtime — upgrading the binary doesn't retroactively protect already-running processes.

Hardening your container stack

Patching runc closes Leaky Vessels, but the same habits blunt the next runtime CVE too:

• Run unprivileged containers wherever possible. On Proxmox, prefer unprivileged LXCs, and inside Docker drop capabilities and avoid --privileged.
• Be picky about images. The realistic attack path is a malicious or trojaned image. Pin digests, prefer official/base images, and don't docker build random Dockerfiles on a host that matters.
• Isolate the blast radius. Keep risky Docker workloads in a dedicated VM rather than nested in an LXC that sits close to the Proxmox host.
• Keep everything current. Leaky Vessels actually covered several related CVEs (including BuildKit issues); a habit of regular apt full-upgrade and container-engine updates is the real fix.

Staying ahead of the next one

Container runtimes are a moving target, and runc/containerd/Docker advisories land regularly. We keep an eye on new entries through CVE Explore, a fast CVE intelligence database, so a single bad runtime release doesn't quietly put every Docker host in the lab at risk.

Bottom line for CVE-2024-21626: if there's a runc binary anywhere in your Proxmox estate, get it to 1.1.12 or newer, recreate your containers, and lean on unprivileged, least-trust container configs going forward.