A container escape turns code execution inside a container into code execution on the host. It almost never depends on the engine: the same primitives work from Docker, Podman, containerd, and a Kubernetes pod, because they all lean on the same kernel features. What differs is only how the dangerous setting was handed to the container, which is why the runtime and orchestration layers link here rather than re-document the breakout.
The primitives group by what makes the escape possible.
Subtopics#
- Privileged configuration: the container was given too much, from the all-in-one privileged flag to a single dangerous capability, raw device access, or a disabled seccomp or AppArmor profile.
- Sensitive mounts: a host path, a runtime control socket, or host procfs and sysfs was bind-mounted into the container.
- Shared host namespaces: the container shares the host PID, network, IPC, or user namespace.
- Runtime and kernel exploits: a code-execution flaw in the OCI runtime or shim, or in the shared host kernel.
- Sandboxed runtime escapes: breaking out of a sandbox that interposes on the kernel, such as gVisor or a microVM runtime.