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 ನಿಮಿಷದ ಓದುಅಕ್ಟೋ 7,2026 ರಂದು ನವೀಕರಿಸಲಾಗಿದೆflorianamette1 ಕೊಡುಗೆದಾರ
ನಿಮ್ಮ ಸಹಾಯಕವನ್ನು ಕೇಳಿ (MCP)GitHub ನಲ್ಲಿ ಸಂಪಾದಿಸಿ

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#

References#

ಹಿಂದಿನದುUnconfined seccomp or AppArmorಮುಂದಿನದು runc and containerd exploits