A container escape is not a hypothetical. CVE-2019-5736 (runc), CVE-2020-15257 (containerd), and CVE-2022-0185 (Linux kernel) are all documented vulnerabilities that enabled escape from container isolation to host access. Each had working proof-of-concept exploits. Each was exploited in real environments before organizations had patched.
Understanding how container escapes actually work is the prerequisite to preventing them systematically.
The Anatomy of a Container Escape
Container isolation relies on Linux kernel primitives: namespaces, cgroups, seccomp, and capabilities. A container escape is any technique that defeats these primitives to gain access to the host OS, other containers on the same host, or the underlying Kubernetes node.
The documented escape techniques fall into several categories:
Kernel Vulnerability Exploitation
The most technically significant escapes exploit vulnerabilities in the Linux kernel itself. Because all containers on a host share the same kernel, a kernel vulnerability that achieves privilege escalation does not stop at the container boundary.
CVE-2022-0185 is the clearest recent example: a heap overflow in the Linux filesystem context API that allowed an unprivileged user to escalate to root and escape the container. The root cause was a bug in a kernel subsystem that virtually no containerized application needs to call. Restricting which system calls a container can make — via seccomp profiles — blocks this class of exploitation: the container cannot call the vulnerable code path if the syscall is denied.
Container Runtime Vulnerabilities
CVE-2019-5736 exploited a vulnerability in runc, the container runtime used by Docker and containerd. An attacker with write access to /proc/self/exe inside a container could overwrite the runc binary on the host, achieving host code execution.
This class of escape requires the attacker to already be executing inside the container. The prerequisite is initial access — typically achieved through an application vulnerability or a compromised container image.
Privileged Container Abuse
Containers run with –privileged have access to all host devices and can modify kernel parameters. A privileged container on a Kubernetes node can mount the host filesystem and read sensitive files, load kernel modules, or use nsenter to enter the host’s namespaces. This is not a vulnerability; it is the intended behavior of privileged mode.
Running privileged containers in production is a configuration mistake with severe security consequences.
Volume and Mount Escapes
Mounting the Docker socket (/var/run/docker.sock) into a container gives that container full control over the Docker daemon. From the Docker daemon, you can create a new privileged container with the host filesystem mounted. This is a complete host compromise via a volume mount.
Sensitive host paths mounted into containers — /etc, /proc, kubelet configuration directories — provide partial access to host resources and expand what a compromised container can do.
What Enables Container Escapes: The Common Thread?
Looking across documented container escapes, two factors appear consistently:
The attacker had initial access to the container. Kernel exploits and runtime exploits both require code execution inside the container. This means container escape prevention starts with preventing initial access — which means reducing the exploitable attack surface of your container images.
The attacker had access to tools. CVE-2019-5736 exploitation required the ability to create files with specific permissions. CVE-2022-0185 exploitation required specific syscall access. Many post-exploitation techniques require utilities like nsenter, mount, bash, or file write capabilities in /proc.
Container security software that removes unnecessary tools from container images limits what an attacker can do after initial access. A container image with no shell, no filesystem utilities, and no network tools is harder to use as an escape launchpad than a container with a full Ubuntu toolset.
Systematic Prevention Controls
Seccomp Profiles
The default seccomp profile blocks 44 system calls. This is a starting point, not a solution. Application-specific seccomp profiles that allow only the system calls your application actually uses provide significantly stronger protection.
Syscall profiling during testing generates the minimal syscall set your application requires. Apply a seccomp profile that denies everything else.
Non-Root Execution
The majority of container escape techniques require privilege escalation from a limited user context to root within the container before attempting host escape. Running containers as non-root users with minimal capabilities eliminates a significant portion of the escalation chain.
Combine non-root execution with allowPrivilegeEscalation: false in your pod security context to prevent setuid and setgid binaries from elevating privileges.
Read-Only Root Filesystems
Many container escape techniques require writing to the container filesystem: creating files, modifying binaries, writing to /proc. A read-only root filesystem with specific writable volume mounts for legitimate application data eliminates the filesystem write vectors.
Minimal Attack Surface Through Image Hardening
A container vulnerability scanner that identifies unnecessary packages in container images is the starting point for attack surface reduction. Packages that provide no application functionality provide only attack surface.
Shells, debugging utilities, package managers, networking tools, and compression utilities should not be present in production container images. Their absence eliminates the tools an attacker would use after achieving initial access.
Kubernetes Admission Controls
Admission controllers enforce that pods are created with required security settings. Pod Security Standards at the Restricted profile deny privileged containers, host namespace sharing, and dangerous volume types. OPA/Gatekeeper or Kyverno policies can extend this to organization-specific requirements.
Frequently Asked Questions
What is a container escape attack?
A container escape attack is any technique that defeats Linux container isolation primitives — namespaces, cgroups, seccomp, and capabilities — to gain access to the host OS, other containers on the same host, or the underlying Kubernetes node. Documented container escape attacks include CVE-2019-5736 (runc), CVE-2020-15257 (containerd), and CVE-2022-0185 (Linux kernel), all of which had working proof-of-concept exploits and were exploited in real environments. Both initial access to the container and access to specific tools inside it are typically required for a successful escape.
How do container escape attacks happen?
Container escape attacks occur through several mechanisms: exploitation of kernel vulnerabilities that affect all containers sharing the host kernel, exploitation of container runtime vulnerabilities in runc or containerd, abuse of privileged container configurations that grant access to all host devices, and exploitation of dangerous volume mounts such as the Docker socket. The common thread across documented container escapes is that the attacker first needs code execution inside the container — typically through an application vulnerability or compromised image — before attempting the escape itself.
How do you prevent container escape attacks?
Preventing container escape attacks requires layered controls: application-specific seccomp profiles that deny syscalls the application does not use (blocking kernel exploit code paths), non-root execution combined with allowPrivilegeEscalation: false, read-only root filesystems, and image hardening that removes tools an attacker would use post-compromise. Kubernetes admission controllers enforce that pods are created with these security settings. Prompt patching of container runtimes, kernel, and Kubernetes nodes remains the baseline defense against known CVEs.
What is the most common method of container escape?
Privileged container abuse is among the most commonly exploited container escape paths — not because it involves a vulnerability, but because it is a configuration mistake that grants full host device access by design. Runtime vulnerability exploitation (as in CVE-2019-5736 targeting runc) and kernel vulnerability exploitation (as in CVE-2022-0185) are the technically significant escape classes. Mounting the Docker socket into a container is another high-severity path that provides complete host compromise through a volume mount without requiring any vulnerability.
Patching as the Baseline
None of the prevention controls above are a substitute for patching. CVE-2019-5736 had a patch. CVE-2022-0185 had a patch. CVE-2020-15257 had a patch. Organizations that applied patches promptly were protected; those that did not were exposed.
Container runtime patching, kernel patching, and Kubernetes node patching are the baseline. The controls above are defense-in-depth for the cases where a zero-day precedes the patch, or where patching cadence has not kept up with disclosure cadence.
The combination of reduced attack surface, strong runtime controls, admission policy enforcement, and prompt patching does not make container escapes impossible — but it makes them significantly harder and significantly more visible.
