Container escape: how attackers reach the host, and how to close it

A container is not a separate machine

It is easy to think of a container as a small virtual machine. It is not. A container is an ordinary process on a kernel shared with the host. The kernel shows it its own slice: its own processes, its own network, its own filesystem. But the kernel is the same one the host uses. A container's isolation is a floor plan inside one apartment, not a separate house.

From that follow two very different ways to "escape" a container onto the host.

Way one: the keys were handed over

Most often nobody breaks anything — host access was granted by configuration.

The docker group is root. The Docker daemon runs as root, and whoever can command it controls the host. Docker's docs ask outright that only trusted people reach the daemon. And starting a container with the host's root mounted is a built-in feature:

docker run -v /:/host --rm -it alpine chroot /host sh
# this is a root shell in the host's files

Nothing was broken: the command did what it promises. So adding someone to the docker group is the same as handing them passwordless sudo.

A mounted socket and --privileged are the same thing in other words. If /var/run/docker.sock is mounted into a container, from inside you can command the host's daemon. The --privileged flag lifts almost all of a container's restrictions. Both are an open door, not a break-in.

Way two: a bug in the shared runtime

This is a real escape: not an open door but a punched wall. Since the kernel and runtime are shared with the host, a bug in them is a way out. That is how two well-known runc bugs worked (CVE-2019-5736 and CVE-2024-21626): both yielded root on the host — because the kernel is shared by everyone. Both are long since fixed; the point is to patch in time.

The figure below shows the two models side by side — a container with a shared kernel and a microVM with a hypervisor — and which boundary each class crosses.

How to close it

• Don't hand out keys. The docker group — trusted people only; don't mount docker.sock; drop --privileged.
• Narrow privileges. Run as a non-root user, drop unneeded privileges, enable rootless mode — then even an escape gives no root on the host.
• Patch runc and don't disable the kernel's defenses (seccomp, AppArmor/SELinux).
• For untrusted code, remove the shared kernel. gVisor, Kata, or a microVM (Firecracker): they have their own kernel and a hypervisor boundary, and the runc class of escapes no longer reaches the host.

What a container is, and where its boundary runs

A container is not a virtual machine. It is a process on the same kernel as the host, to which the kernel shows a trimmed view of the world: its own process IDs, its own network, its own filesystem — those are namespaces. How much resource it may use is decided by control groups (cgroups). What it is allowed to do in the kernel is limited by a set of capabilities.

The key word is "shared." All three mechanisms live in one kernel with the host. So a container's isolation is not the wall of a virtual machine but a floor plan inside one apartment. NIST's container security guide puts containers on a boundary weaker than a hypervisor's outright. Both escape classes grow from that: somewhere the floor plan was given away, somewhere it was punched through by a bug.

What counts as trusted here

Before the list of defences it is worth settling the frame, or the argument "is a container secure" has no answer. NIST's container security guide sets that frame twice.

The first is about the class of boundary, and it is stated outright:

The reason is named in the same document, in the section on the shared kernel:

The second is where the document draws the boundary of its own scope, and that list is exactly what to keep in mind while reading any promise of isolation:

Hence the practical conclusion, which is the threat model in one line: everything that shares your kernel, you treat as equally trusted. Not "isolated" but trusted — because the boundary between them is weaker than a hypervisor's, and it is configured by you rather than by a vendor.

It follows too that the runtime is part of the boundary. There is no direct "keep your runtime current" requirement in the document; there are three neighbouring statements from which it follows. A runtime vulnerability leads to escape: While relatively uncommon, vulnerabilities within the runtime software are particularly dangerous if they allow "container escape" scenarios. And hence the obligation: The container runtime must be carefully monitored for vulnerabilities, and when problems are detected, they must be remediated quickly.

And from "equally trusted" follows a placement rule, named in the document explicitly:

So the decision "where do we run this" is taken before the configuration, not after it: by whether purpose, sensitivity and threat posture match the neighbours'.

Class 1: the escape that never was — handed keys

The most common "hole" is not a hole. Control of the host was given away by configuration, and the attacker only has to use it. Three typical cases; in all three kernel isolation is irrelevant.

The docker group is root on the host

The Docker daemon runs as root. Whoever can give it commands effectively controls the host. Docker's documentation says so outright: "Only trusted users should be allowed to control your Docker daemon." Membership in the docker group grants exactly that control — no sudo, no password.

Why that equals root is clear from another passage in the same docs. Docker lets you mount any host directory into a container without restricting access: "you can start a container where the /host directory is the / directory on your host; and the container can alter your host filesystem without any restriction." So anyone who can start a container can mount the host's root and write to it:

docker run -v /:/host --rm -it alpine chroot /host sh
# this is now a root shell in the host's filesystem

This is not an exploit or a vulnerability — it is documented behaviour. No isolation mechanism failed here: the command did exactly what it promises. So the docker group is not "a convenience for developers" but a grant of root, and it should be treated like handing out passwordless sudo.

A mounted docker.sock

The same thing, from inside a container. If /var/run/docker.sock is mounted into a container (a common trick for CI and "Docker-in-Docker"), the process inside gets a channel to the host's daemon — and therefore everything the docker group gives: ask for a new container with / mounted. OWASP makes this rule number one: "Do not expose the Docker daemon socket (even to the containers)" — "Giving someone access to it is equivalent to giving unrestricted root access to your host."

--privileged and extra capabilities

The --privileged flag lifts almost every restriction: it hands the container the full set of capabilities, access to host devices, and drops the seccomp and AppArmor profiles. From such a container the host is one step away. The same goes for individual dangerous privileges like CAP_SYS_ADMIN, or bind-mounting host paths. OWASP: "Do not run containers with the --privileged flag."

Takeaway for class 1: most "container escapes" in real incidents are this one. Breaking the kernel is not required, because host access was handed over by configuration. The good news: it is closed by configuration too — see below.

Class 2: the real escape — a bug in the shared runtime or kernel

Now the "escape" in the strict sense: the attacker crosses a boundary nobody opened. Since the kernel and runtime are shared with the host, a bug in them is a bridge outward. Two known examples — by what failed, with no reproduction steps.

CVE-2019-5736. Verbatim: "runc through 1.0-rc6 … allows attackers to overwrite the host runc binary (and consequently obtain host root access)." What failed was not a kernel isolation mechanism but runc — the runtime shared by the container and the host. Overwriting it could yield root on the host.

CVE-2024-21626. Verbatim: "due to an internal file descriptor leak, an attacker could cause a newly-spawned container process … to have a working directory in the host filesystem namespace." The runtime again; fixed in runc 1.1.12. A descriptor pointing into the host's filesystem was reachable from inside — because there is only one, shared kernel.

What both share: the container and the host have one kernel, and a runtime failure bridges to it. That is what makes class 2 possible at all — and it points to the one defense that removes it entirely (the last section).

How to close it

Defense is layered: first don't hand out access (class 1), then narrow what remains, and finally — for untrusted code — remove the shared kernel (class 2). The rules below come from the OWASP Docker Security Cheat Sheet and Docker's docs.

Don't hand out control of the daemon.

• The docker group — trusted people only; treat membership as sudo and audit it regularly.
• Don't mount /var/run/docker.sock into containers; don't expose the daemon over TCP.
• Rootless mode: the daemon and containers run as an unprivileged user, so even a container escape does not give root on the host.

Narrow the container's privileges.

• No --privileged. Drop all capabilities and add back only what is needed.
• Run as a non-root user inside the container — OWASP calls this the best way to prevent privilege escalation.
• --security-opt=no-new-privileges so setuid binaries cannot raise privileges.
• --read-only for the root filesystem wherever possible.

Keep the kernel's own defenses on.

• Don't disable the default seccomp profile; keep AppArmor or SELinux.
• Enable user namespaces: root inside the container stops being root on the host.

Against class 2 — patches and a different boundary.

• Patch the runtime: keep runc on the current patch release of its branch and read the project's security advisories. Naming a specific version here would be pointless: it moves with every advisory, and yesterday's “new enough” is today's vulnerable.
• For untrusted code, remove the shared kernel entirely: gVisor (system-call interception), Kata Containers, or a microVM (Firecracker). They have their own guest kernel, their boundary with the host is a hypervisor with a narrow interface, and the runc class of escapes no longer reaches the host: there is nothing to break through, no shared kernel.

The same thing in Kubernetes: three levels, and what each forbids

Everything said above about docker run flags is expressed declaratively in Kubernetes, and the list need not be assembled by hand: it is standardised as three policies.

"Cumulative" is doing work here: Restricted includes everything in Baseline.

Privileged is the absence of restrictions, and the documentation does not soften it: Unrestricted policy, providing the widest possible level of permissions. This policy allows for known privilege escalations. It is meant for system workloads run by trusted people — that is, for the very "the keys were handed over deliberately" case of class 1 above.

Baseline is Minimally restrictive policy which prevents known privilege escalations. Five of its rows map onto "How to close it" one for one — the same prohibitions, written as manifest fields (the policy itself has more controls; only the overlapping ones are here):

Baseline's allowed capability list is thirteen names: AUDIT_WRITE, CHOWN, DAC_OVERRIDE, FOWNER, FSETID, KILL, MKNOD, NET_BIND_SERVICE, SETFCAP, SETGID, SETPCAP, SETUID, SYS_CHROOT.

Restricted is Heavily restricted policy, following current Pod hardening best practices, and what it adds is what was called "narrow the privileges" above:

Note the difference in the seccomp row: Baseline forbids turning the profile off, Restricted requires setting it explicitly — the absence of a profile is forbidden too. Those are different requirements, and the second is stronger.

Take the fields' semantics from the API types rather than from retellings. The two places people get wrong most often:

So you cannot set allowPrivilegeEscalation: false and leave privileged mode on at the same time: the second wins, silently.

runAsNonRoot: true is a check, not an assignment of a user. An image built to run as root will not start under it; the user has to be set in the image or through runAsUser.

How this is switched on. The policies are applied by namespace labels — pod-security.kubernetes.io/<mode>: <level> — and there are three modes: enforce (Policy violations will cause the pod to be rejected), audit and warn. The rollout order follows by itself: warn and audit first, then enforce once the list of violations is empty.

And what closes class 2. Removing the shared kernel in Kubernetes is not a separate infrastructure but a field in the manifest: RuntimeClass has been stable since 1.20.

That is the same decision as "gVisor or Kata for untrusted code" in the previous section, only taken per Pod rather than per node. And it is taken by the same rule as in the threat model above: by whether purpose, sensitivity and threat posture match.

What to take away

"Container escape" is most often not a break-in but a grant of privilege. Before reaching for a CVE, check the configuration: who is in the docker group, where the socket is mounted, where --privileged is set. Class 1 is closed by hygiene, not patches.

The docker group = root on the host. This is documented behaviour, not a vulnerability. Granting it is the same as granting passwordless sudo.

A real escape relies on a shared kernel. Patches (runc) close known holes; but while the kernel is shared, the class remains. Only a different boundary removes it — gVisor, Kata, a microVM.

Ask not "can the container be broken," but "what did we hand over, and what boundary protects the rest." For an ordinary container that is a floor plan on a shared kernel; for a microVM it is a hypervisor, whose surface is an order of magnitude smaller.