Container Escape

What is Container Escape?

A container escape is an attack in which a threat actor exploits a vulnerability or misconfiguration to break out of the isolation boundary of a running container — such as a Docker container or a Kubernetes pod — and gain unauthorized access to the underlying host operating system or other containers on the same host. Container escapes represent some of the most critical vulnerabilities in cloud-native infrastructure because they allow an attacker who starts with limited, containerized code execution to achieve full host compromise and, in Kubernetes clusters, potential cluster-wide access. Three critical runC CVEs disclosed in late 2025 — CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881 — and a Docker Engine flaw in April 2026 (CVE-2026-34040) demonstrated that container escape vulnerabilities continue to emerge in the foundational runtimes used by Docker, Kubernetes, and virtually all managed cloud container services.

Description

Container isolation relies on Linux kernel primitives — namespaces, cgroups, and seccomp profiles — to restrict what a containerized process can see and do. When these primitives are misconfigured, when the kernel has exploitable vulnerabilities, or when container orchestration is improperly configured, an attacker with code execution inside a container can escape to the host. Common container escape vectors include: privileged container configurations that grant containers near-root access to the host kernel; unsafe volume mounts that expose host filesystem paths inside containers; exposed Docker sockets that allow API access to the Docker daemon; kernel vulnerabilities exploitable from within a container context; and misconfigurations in Kubernetes RBAC that allow pods to escalate to cluster-admin privileges. Kubernetes security overlaps significantly with container escape: Kubernetes clusters with misconfigured admission controls, weak RBAC policies, and unmonitored privileged pod deployments provide multiple paths from container compromise to cluster-wide control. Container escape risk compounds in CI/CD pipelines where build systems run untrusted code — an attacker who can supply a malicious Dockerfile gains a potential escape vector into the build infrastructure. This connects to supply chain attack scenarios where a compromised container image in a registry is pulled and executed by automated pipelines.

Usage and Examples

During a cloud penetration testing engagement, a tester identifies a Kubernetes deployment that runs a build agent container in privileged mode. Using a mounted Docker socket, the tester creates a new privileged container with the host filesystem mounted, writes an SSH key to the root user's authorized_keys file on the host, and achieves persistent root access to the underlying node — all from an initial foothold inside a build agent container. The entire attack chain exploited a single misconfiguration (privileged mode + Docker socket exposure) rather than a software vulnerability. Runtime security tools like Falco and Sysdig Secure detect anomalous container behavior — unusual system calls, unexpected process executions, container breakout indicators — and can block or alert on container escape attempts in real time.

How Does This Relate to Penetration Testing?

Container escape scenarios are a focus area in cloud penetration testing engagements, particularly for organizations running Kubernetes workloads. Evolve Security testers evaluate container configurations for privilege escalation paths, dangerous volume mounts, exposed Docker sockets, weak Kubernetes RBAC, and missing admission controls — building attack chains that demonstrate what an attacker with initial container foothold access could achieve. AWS pentesting best practices and knowledge of cloud-specific container service configurations inform how these assessments are scoped for EKS, AKS, and GKE environments. Evolve Security's Cloud Penetration Testing service evaluates your container and Kubernetes configurations for escape paths, privilege escalation, and cluster-wide compromise scenarios.