Runtime and kernel exploits

Container escapes that rely on a vulnerability rather than a misconfiguration: bugs in the OCI runtimes and shims (runc, containerd, CRI-O) that are reachable during the container lifecycle and break out to the host, and vulnerabilities in the single shared host kernel that a container process can trigger to gain host code execution.

1 min di letturaaggiornato il 7 ott 2026

1 contributore

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:

bash

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.

Runtime and kernel exploits

Subtopics#

References#