What kind of vulnerability were the runc escapes CVE-2019-5736 and CVE-2024-21626, and what did they let an attacker do?

### Where runc sits When you `docker run`, the request flows dockerd -> containerd -> a `containerd-shim` -> **runc**, the small OCI-spec runtime that sets up namespaces, cgroups and mounts and then `exec`s your process. runc runs as **root on the host** for that instant. That makes it the container trust boundary: if the container can subvert runc, it subverts the host, and *no amount of container configuration* -- non-root user, dropped capabilities, seccomp, read-only rootfs -- can defend a flaw inside the runtime itself. That is the theme uniting these two CVEs. ### CVE-2019-5736 -- overwriting runc via /proc/self/exe To enter a container, runc re-executes itself using the magic symlink `/proc/self/exe`, which points at the running runc binary **on the host**. The flaw: a malicious image's entrypoint (or a process the attacker controlled when an operator ran `docker exec`) could open `/proc/self/exe` for writing and overwrite the host's runc binary. The next time anyone started or exec'd into a container, the tampered runc ran the attacker's code as root on the host. A single malicious image that an admin merely `exec`'d into could take the machine. The fix has runc copy itself into a read-only, sealed `memfd` before re-executing, so the on-disk binary can no longer be clobbered through `/proc/self/exe`. ### CVE-2024-21626 -- Leaky Vessels and the leaked fd In vulnerable runc versions, an internal file descriptor referring to a **host** directory (in the `/sys/fs/cgroup` area) was left open -- leaked -- into the container's process. If the container's working directory was set to `/proc/self/fd/<n>` for that leaked descriptor, the path resolved into the **host** filesystem rather than the container's, giving the process read/write access to host files outside the container. Because `WORKDIR` in a Dockerfile is honoured by runc, this was exploitable **at build time** too: merely building a malicious Dockerfile (or one `FROM` a malicious base) with a crafted `WORKDIR` could read or write host files on an unpatched engine -- not only running an untrusted image. It affected other consumers of the same runc (BuildKit, buildah, containerd). Fixed in runc 1.1.12 by closing the leaked descriptors. ### Why config hardening did not help The uncomfortable lesson: containers running as an unprivileged UID, with `--cap-drop ALL`, the default seccomp profile and a read-only rootfs were **still vulnerable** to both. All those controls constrain the *containerised process*; they do nothing about a defect in the *runtime that launches it*. A Python ML inference image built from `FROM python:slim` and pinned to a non-root user is not protected by any of that if the host's runc is unpatched. So runtime CVEs sit alongside misconfiguration as a distinct escape surface. ### The defence 1. **Keep runc/containerd/Docker patched.** These fixes ship in the engine, not your image -- CVE-2019-5736 in Docker 18.09.2, CVE-2024-21626 in Docker 25.0.2 (runc 1.1.12). This is why 'keep the engine current' is a security control, not just hygiene. 2. **Do not build or run untrusted images/Dockerfiles on shared hosts**, especially unpatched ones -- CVE-2024-21626 made even `docker build` of an untrusted Dockerfile dangerous. 3. **Isolate build/run of low-trust content** so a runtime escape, if one recurs, lands somewhere with a small blast radius. Knowing the exact CVE numbers is differentiator-level trivia; the enduring point a strong candidate carries is that the runtime is a trust boundary you patch, because container configuration cannot save you from a hole in runc.