Container Escape: How Attackers Break Out of Docker

A container escape is when an attacker who has code execution inside a Docker container manages to break out and gain access to the underlying host machine, turning a single compromised application into full control of the server — and often every other container running on it. The most common paths in are privileged containers, a mounted docker.sock, exposed host paths, and excess Linux capabilities like CAP_SYS_ADMIN — all misconfigurations, not exotic zero-days. For Indian DevOps and platform teams running production workloads on Docker or Kubernetes, understanding these breakout techniques through authorised testing is the difference between one compromised microservice and a fully owned host.

Why Container Isolation Fails in Practice

Containers are not virtual machines. A container shares the host's kernel — there is no hardware-level hypervisor boundary between a container process and the host operating system. Isolation comes entirely from Linux kernel primitives: namespaces (which limit what a process can see), cgroups (which limit what it can consume), and capabilities plus seccomp/AppArmor/SELinux (which limit what it can do). Get any one of these configurations wrong, and the "boundary" between container and host becomes theoretical.

This matters because container adoption in India has moved fast — most modern SaaS, fintech, and D2C platforms now run Docker in production, frequently orchestrated with Kubernetes. Speed of adoption has consistently outpaced hardening discipline: default configurations get shipped to production, --privileged flags get added "just to fix this one build issue" and never removed, and the Docker socket gets mounted into a CI container because a tutorial said to.

The Core Container Escape Techniques

1. Privileged Containers

Running a container with --privileged disables almost every isolation mechanism Docker provides. A privileged container gets access to all host devices, can load kernel modules, and effectively runs with root-equivalent power over the host kernel. Once inside a --privileged container, an attacker can mount the host's root filesystem directly (via /dev/sda1 or similar) and chroot into it, gaining a full read/write host shell in seconds. This flag is common in CI/CD runners, Docker-in-Docker setups, and "it works when I add privileged" fixes that never get reverted.

2. Mounted Docker Socket (docker.sock)

Mounting /var/run/docker.sock into a container — often done so a container can spin up sibling containers — hands that container the ability to talk directly to the Docker daemon on the host. Anyone with write access to that socket can ask the daemon to create a brand-new container with the host's root filesystem bind-mounted in, then simply chroot into it. This is functionally equivalent to giving that container root on the host, regardless of what user or capability restrictions exist inside the original container itself.

3. Dangerous Host Path Mounts

Bind-mounting sensitive host directories into a container — /, /etc, /root, /var/run, or the host's /proc — gives container processes read/write access to host files. A mount of /etc lets an attacker overwrite /etc/passwd or drop a cron job or SSH key that executes on the host. A mount of /proc with insufficient restriction can, in some kernel/configuration combinations, be abused to reach host process memory or trigger core-dump-based code execution. The general pattern: any host path mount is a door, and the width of that door depends entirely on what's on the other side of it.

4. Excess Linux Capabilities — CAP_SYS_ADMIN and Friends

Docker drops many capabilities by default, but --cap-add is used liberally to unblock functionality, and CAP_SYS_ADMIN in particular is often called "the new root" because of how much it unlocks: mounting filesystems, manipulating namespaces, and — critically — abusing kernel features like release_agent in cgroups v1 to get the host to execute an attacker-controlled script. Other capabilities worth flagging in an audit include CAP_SYS_PTRACE (process inspection/injection across namespace boundaries in some configurations) and CAP_DAC_READ_SEARCH (bypassing filesystem permission checks, historically tied to breakout proof-of-concepts).

5. Kernel Exploits

Because containers share the host kernel, any unpatched kernel-level vulnerability is a potential breakout vector regardless of container configuration. Runc — the low-level runtime underlying Docker and most container platforms — has had publicly disclosed vulnerabilities (notably CVE-2019-5736) that allowed a malicious container to overwrite the host runc binary and achieve host code execution on subsequent container starts. This class of issue underscores that container security is not just configuration hygiene — it also depends on keeping the container runtime and host kernel patched.

The Container Escape Path

How Common Is Each Root Cause

Across published container-security research and CTF/red-team writeups, the same handful of root causes recur far more often than kernel-level zero-days. The distribution below is a qualitative summary of relative frequency, not a single-source statistic.

Privileged vs Rootless vs Hardened — A Comparison

Defence: Hardening the Container Boundary

Drop unnecessary capabilities. Start every container from --cap-drop=ALL and add back only the specific capabilities the application genuinely needs. Most web applications, APIs, and background workers need none of the dangerous ones.

Never run --privileged in production. If a workload genuinely needs elevated device or kernel access, scope it to the exact capability required instead of the blanket flag, and isolate that workload on its own host.

Never mount docker.sock into application or CI containers. If sibling-container orchestration is required, use a dedicated, access-controlled build API or a purpose-built solution designed for that pattern, not a raw socket mount into a general-purpose container.

Go rootless where possible. Rootless Docker runs the daemon and containers under an unprivileged host user, so even a full container compromise doesn't hand over host root by default.

Apply seccomp and AppArmor/SELinux profiles. Docker ships a default seccomp profile that blocks dozens of dangerous syscalls; disabling it (--security-opt seccomp=unconfined) for convenience removes a meaningful layer of defence. Keep it on, and layer AppArmor or SELinux mandatory access control on top.

Mount the filesystem read-only and avoid host paths. Use --read-only with explicit writable volumes where needed, and audit every bind mount for necessity and scope — mount the narrowest possible path, never /, /etc, or /proc wholesale.

Patch the runtime and kernel. Runc, containerd, and the host kernel are part of the attack surface. Track CVEs against your container runtime the same way you'd track them against any other production dependency.

Testing Container Security the Right Way

Container breakout testing should be part of any authorised VAPT engagement that includes containerised infrastructure — reviewing Dockerfiles and runtime flags for --privileged usage, auditing every bind mount and added capability, checking whether the Docker socket is exposed anywhere in the environment, and confirming seccomp/AppArmor profiles are actually enforced rather than assumed. At Bachao.AI, automated VAPT scans are built to surface exactly these misconfigurations across containerised environments before an attacker finds them first. Dhisattva AI Pvt Ltd designed the platform around the reality that most container compromises trace back to a handful of well-known, fixable configuration gaps rather than sophisticated kernel research. Indian DevOps and platform teams running Docker or Kubernetes in production can start with a free VAPT scan to check container and host hardening posture, and teams handling regulated or personal data should also review our DPDP compliance guide. More infrastructure security breakdowns are available on our blog. Where a CERT-In empanelled assessment is required for compliance or tender purposes, this is available with a CERT-In empanelled partner.

For further technical reference, the NIST Application Container Security Guide (SP 800-190) and the CERT-In advisories portal both cover container and infrastructure hardening guidance relevant to Indian organisations.

Frequently Asked Questions