Database/Container, Kubernetes & orchestration
runc: Host runc binary overwritten from inside a container
Impact
Host runc binary overwritten from inside a container; full host root. The canonical container-escape
Who can reach it
Any tenant workload that can exec as root in its own container, or a malicious image
What to do
Replace the runc binary on every node; already-running containers keep the vulnerable fd, so a full drain and pod restart is required
Fleet impact
How widespread
Universal - the original runc escape; affected Docker, containerd and CRI-O simultaneously
Cost to remediate
node-drain - the host runc binary itself is overwritten by the exploit, so remediation is binary replacement plus recreation of every container; the standing mitigation is making runc immutable
Why it hits the whole fleet
A container process rewrites /proc/self/exe and overwrites the *host* runc binary, so every subsequent container start on that host executes attacker code as root - the canonical fleet-wide container-runtime emergency
References
Related entries
- runc: "Leaky Vessels": internal file descriptor leak lets a container process start with cwd in the host filesystemCVE-2024-21626 · runcHigh
- runc: Container filesystem breakout via directory traversal in mount handlingCVE-2021-30465 · runcHigh
- runc: Insufficient checks when bind-mounting /dev/console allow writes to arbitrary host procfs pathsCVE-2025-52565 · runcHigh
- runc: AppArmor restriction bypass via mount-target check flawCVE-2019-16884 · runcHigh
- runc: Insufficient verification of masked-path bind mounts (/dev/null replaced by symlink) enables containerCVE-2025-31133 · runcHigh
- runc: Attacker misdirects runc writes to /proc via racing symlinksCVE-2025-52881 · runcHigh
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.