TL;DR: Containers are not virtual machines and were never designed as a security boundary. They share the host kernel and rely on Linux namespaces, cgroups, seccomp, and capability restrictions for isolation — all of which can be bypassed through misconfigurations or kernel vulnerabilities. Privileged containers, mounted Docker sockets, excessive capabilities, and sensitive host mounts are the most common escape paths pentesters exploit. Understanding these techniques is essential for securing containerized infrastructure, because the consequence of a container escape is full host compromise — and from there, access to every other container on the host.
Container Escape Techniques: Severity and Frequency
| Escape Technique | Severity | Frequency in Production | Prerequisite |
|---|---|---|---|
| Privileged Container | Critical | High | --privileged flag or equivalent |
| Mounted Docker Socket | Critical | Medium-High | /var/run/docker.sock mounted |
| CAP_SYS_ADMIN Abuse | Critical | Medium | SYS_ADMIN capability granted |
| Kernel Exploit | Critical | Low-Medium | Unpatched host kernel |
| Cgroup Escape (notify_on_release) | Critical | Low | CAP_SYS_ADMIN + cgroup v1 |
| Sensitive Host Mount | High-Critical | Medium | Host paths mounted into container |
| procfs/sysfs Abuse | High | Medium | Writable /proc or /sys mounts |
Privileged Containers: No Isolation at All
Running a container with the --privileged flag disables virtually every isolation mechanism Docker provides. The container gains access to all host devices (including /dev/sda — the host disk), all Linux capabilities are granted, AppArmor and seccomp profiles are disabled, and the container can see and interact with the host's kernel interfaces directly. A privileged container is, from a security perspective, functionally equivalent to running as root on the host.
The escape from a privileged container is trivial. An attacker can mount the host filesystem by accessing the host's block device directly. With the host filesystem mounted, the attacker can read /etc/shadow, write SSH public keys to root's authorized_keys, modify crontab entries for persistent access, or plant a reverse shell in a system startup script. The entire process takes seconds once the attacker determines they are in a privileged container.
Despite the well-documented risks, privileged containers remain common in production. They appear in CI/CD pipelines that need to build Docker images (Docker-in-Docker), monitoring agents that need access to host metrics, and development environments where engineers add --privileged to fix permission errors without understanding the security implications.
Remediation: Never use --privileged in production. For Docker-in-Docker requirements, use Kaniko or buildkit with rootless mode. For host metric access, mount only the specific /proc or /sys paths needed, read-only. Implement Pod Security Standards (in Kubernetes) or Docker daemon configuration to prevent privileged containers from being created.
Mounted Docker Socket: Creating Your Own Escape
Mounting the Docker daemon socket (/var/run/docker.sock) into a container is the second most common container escape vector. This pattern is used by monitoring tools, log aggregators, CI/CD systems, and container management UIs. It grants the container the ability to communicate with the Docker daemon on the host — and the Docker daemon runs as root.
An attacker with access to the Docker socket can create a new container with arbitrary configuration: privileged mode enabled, the host root filesystem mounted at a chosen path, and host networking. The new container provides unrestricted root access to the host. The attacker does not need to exploit any vulnerability — they are using the Docker API exactly as designed.
This escape is particularly dangerous because it is not a vulnerability in the traditional sense — it is a feature being used as intended. The Docker socket grants the same permissions as root SSH access to the host. Any container with access to the socket should be treated as having full host compromise capability.
Remediation: Avoid mounting the Docker socket into containers. For tools that require Docker API access, use docker socket proxies (like Tecnativa's docker-socket-proxy) that filter API calls and restrict the operations available to the container. In Kubernetes, avoid mounting the container runtime socket and use the Kubernetes API with RBAC instead.
Kernel Exploits: Shared Kernel, Shared Vulnerabilities
Unlike virtual machines, containers share the host kernel. A vulnerability in the Linux kernel is exploitable from within any container on the host, regardless of that container's configuration. This is the fundamental limitation of container isolation — and it means that kernel patching is a container security concern, not just a host concern.
Notable Container-Escape Kernel CVEs
CVE-2022-0185 (Heap Overflow in Filesystem Context): This kernel vulnerability allowed an unprivileged user in a user namespace to trigger a heap overflow in the legacy filesystem context parsing code. Since Docker containers have user namespaces by default (though they map to the same underlying kernel), this could be exploited from within a container to achieve kernel code execution and escape to the host. The exploit required CAP_SYS_ADMIN within the user namespace — which is available by default inside containers.
CVE-2022-0847 (Dirty Pipe): This vulnerability allowed overwriting data in arbitrary read-only files by exploiting a flaw in the Linux pipe subsystem. From within a container, an attacker could overwrite files in the container's filesystem that are backed by read-only host filesystem layers — including binaries executed by the host. This could be leveraged for container escape by overwriting a binary or script that the host executes, injecting code that runs with host-level privileges.
CVE-2024-1086 (nf_tables Use-After-Free): A use-after-free vulnerability in the netfilter subsystem allowed local privilege escalation. Exploitable from within containers with network namespace access, this vulnerability could be chained with other techniques to achieve host-level code execution from a non-privileged container.
Remediation: Maintain aggressive kernel patching schedules. Use container-optimized operating systems (Bottlerocket, Flatcar, Talos) that minimize the host attack surface. Deploy runtime security tools (Falco, Sysdig Secure) that detect exploit behavior patterns — unexpected system calls, unusual process trees, and capability usage that indicates exploitation attempts.
Cgroup Escape via notify_on_release
The cgroup escape technique exploits the notify_on_release mechanism in cgroup v1 to execute commands on the host from within a container. When a cgroup's notify_on_release flag is set and all processes in the cgroup exit, the kernel executes the path specified in the cgroup's release_agent file — and this execution happens in the host's context, not the container's.
The attack requires CAP_SYS_ADMIN (to mount a cgroup filesystem and write to its configuration files) and cgroup v1 (cgroup v2 removed the release_agent mechanism). The attacker creates a new cgroup, sets its notify_on_release to 1, writes a path to a host-accessible script as the release_agent, then triggers notification by adding and removing a process from the cgroup. The kernel executes the release agent script as root on the host.
Remediation: Drop CAP_SYS_ADMIN from containers (it should never be granted unless absolutely necessary). Migrate to cgroup v2, which does not support the release_agent mechanism. Use seccomp profiles that restrict the system calls needed to mount filesystems within containers.
Capability Abuse: CAP_SYS_ADMIN and Beyond
Linux capabilities split the traditional root privilege into discrete units. Docker drops most capabilities by default, but operators frequently add capabilities back to resolve specific permission requirements without understanding the security implications. CAP_SYS_ADMIN alone enables dozens of privileged operations including mounting filesystems, modifying cgroups, and performing trace operations — each of which can be leveraged for container escape.
Other capabilities with escape potential include CAP_SYS_PTRACE (trace and modify other processes — potentially including host processes visible through /proc), CAP_NET_ADMIN (modify network configuration, potentially enabling traffic interception), CAP_SYS_RAWIO (direct hardware access including I/O ports), and CAP_DAC_READ_SEARCH (bypass file read permission checks, enabling access to any file in the container's mount namespace).
Remediation: Run containers with the minimal set of capabilities required. Start with --cap-drop=ALL and add back only specific capabilities that the application needs. Audit running containers for unnecessary capabilities and remove them. In Kubernetes, enforce capability restrictions through Pod Security Standards or OPA/Gatekeeper policies.
Kubernetes Implications
In Kubernetes environments, a container escape has amplified consequences. The compromised host is a Kubernetes node, and the node has a kubelet service account token, access to the Kubernetes API, and potentially access to secrets mounted into other pods on the same node. An attacker who escapes to the node can read secrets from other pods' volumes, impersonate the kubelet to the API server, access the container runtime to compromise other containers, and potentially pivot to the control plane if RBAC is misconfigured.
Kubernetes-specific mitigations include Pod Security Standards (enforcing restricted profiles that prevent privileged containers, host mounts, and excessive capabilities), network policies that restrict pod-to-pod communication, runtime security monitoring on each node, and regularly rotating node credentials and service account tokens.
Test Your Container Security Before Attackers Do
Lorikeet Security's infrastructure penetration testing includes container escape assessment — privileged container identification, Docker socket exposure, capability analysis, kernel vulnerability assessment, and Kubernetes RBAC review. Find the escape paths in your containerized environment before a real attacker does.
