runc and containerd exploits

The low-level runtimes runc, containerd, and CRI-O run as root on the host and process attacker-influenced data during container lifecycle operations. Known breakouts include overwriting the runc binary through /proc/self/exe, file-descriptor and path leaks that reach the host filesystem, CRI-O's unvalidated kernel parameter setting, and reachable container shim APIs.

1 min di letturaaggiornato il 7 ott 2026florianamette1 contributore
Chiedi al tuo assistente (MCP)Modifica su GitHub

runc is the reference OCI runtime that actually creates and enters containers; containerd and CRI-O sit above it and manage images, shims, and lifecycle. All run as root on the host, and all handle data the container controls: the image filesystem, the process spec, working directories, mount paths, and annotations. A bug in how any of them handles that data during create, start, or exec runs with host root privilege, so these are full escapes rather than escalations.

Fingerprint the runtime versions, which decide which flaw applies:

bash
runc --version 2>/dev/null
containerd --version 2>/dev/null
crictl version 2>/dev/null
cat /proc/self/cgroup                       # hints at the managing runtime

Subtopics#

References#