Where a container is correctly locked down, with no extra capabilities, no sensitive mounts, and no shared namespaces, escaping requires a vulnerability. Two surfaces matter. The first is the container runtime itself: runc, containerd, and CRI-O run as root on the host and touch attacker-controlled data (image contents, process specs, file paths) during create, start, and exec, so a flaw there executes on the host by construction. The second is the host kernel, which is shared by every container regardless of isolation, so a kernel bug a container process can reach is a kernel bug on the host.
Fingerprint the versions that decide which flaws apply:
runc --version 2>/dev/null; containerd --version 2>/dev/null; crictl version 2>/dev/null
uname -r # host kernel release gates the kernel bugs
cat /proc/self/uid_map # user-namespace reach for unprivileged kernel bugs
Subtopics#
- runc and containerd exploits: runtime and shim flaws reachable from a crafted image or workload.
- Kernel exploits: shared-kernel vulnerabilities triggerable from a container.