Container Escape: How Attackers Break Out of Docker and Into Your Host

Containers revolutionized deployment, but they introduced a dangerous assumption: that container isolation equals security isolation. In practice, containers share the host kernel, and the boundary between container and host is thinner than most teams realize. Container escape — breaking out of a container to access the host system — is a well-documented attack class with techniques ranging from kernel exploits to simple misconfigurations.

Understanding the Container Boundary

A container is not a virtual machine. It's a set of Linux kernel features — namespaces, cgroups, and capabilities — that create the illusion of isolation. The container shares the host's kernel. A kernel vulnerability exploitable from within a container grants access to the host. This is fundamentally different from a VM, where a hypervisor provides hardware-level isolation.

This distinction matters because container images are often less trusted than VM images. Teams pull base images from public registries, install untrusted packages, and run code from third-party dependencies — all sharing a kernel with the host and other containers.

Escape via Misconfiguration

The most common container escapes don't require exploits — just misconfigurations:

• Privileged containers: Running a container with --privileged disables most security features. The container can mount the host filesystem, load kernel modules, and access all devices. It's effectively root on the host.
• Docker socket mounting: Mounting /var/run/docker.sock into a container gives it full control over the Docker daemon. The container can create new privileged containers, access any container's filesystem, and execute commands on the host.
• Host PID namespace: Running with --pid=host lets the container see and interact with all processes on the host, enabling ptrace-based attacks and signal injection.
• Excessive capabilities: Linux capabilities like CAP_SYS_ADMIN, CAP_NET_ADMIN, or CAP_SYS_PTRACE provide specific escalation paths when granted to containers that don't need them.

Escape via Kernel Exploits

Since containers share the host kernel, any kernel privilege escalation vulnerability is a container escape. Notable examples:

• CVE-2022-0185: A heap overflow in the Linux filesystem context API, exploitable from within an unprivileged container to gain root on the host.
• CVE-2022-0847 (Dirty Pipe): A Linux kernel vulnerability allowing overwriting data in arbitrary files, exploitable from within containers to modify host files.
• CVE-2024-21626 (Leaky Vessels): A vulnerability in runc (the container runtime) allowing container escape through a race condition in the working directory setup.

These aren't theoretical. They're assigned CVEs with public proof-of-concept exploits that were used in real attacks.

Kubernetes-Specific Risks

Kubernetes adds its own escape vectors on top of container-level risks:

• Overprivileged service accounts: Pods with cluster-admin permissions can control the entire cluster.
• Exposed metadata API: The cloud provider's metadata service is accessible from pods by default, exposing IAM credentials.
• etcd access: If an attacker reaches the etcd database (which stores all cluster state), they can read every secret and modify any configuration.

The Web Application Connection

Container escapes typically require initial access to execute code within the container. That initial access often comes through the web application running inside it — an RCE vulnerability, an SSRF that reaches internal services, or a deserialization flaw. The container is only the second step. The web application's security posture is the first line of defence.

ShieldReport evaluates the security configuration of your web-facing applications — the entry point attackers must breach before attempting deeper infrastructure compromise — ensuring your external posture doesn't invite the initial access that makes container escape relevant.