Container Escape

Domain

Infrastructure & systems

ROOTVIEL support

Educational — Recognized concept, documented for learning — not detected by ROOTVIEL.

CWE

CWE-269, CWE-250

OWASP

A05:2021

A container escape is any event in which code confined to a container obtains execution or control outside that container — typically on the host kernel, the container runtime, or a peer container. A container is not a virtual machine: it is a set of Linux kernel features (namespaces, cgroups, capabilities, seccomp, LSMs) that constrain an ordinary process that still shares the host kernel. An escape is the failure of that constraint, after which the attacker operates with whatever privilege the breakout path granted — often root on the node.

The escape itself is rarely a single exotic exploit. Far more often it is the direct consequence of how the container was configured: a capability that should have been dropped, a host path that should never have been mounted, a namespace that should not have been shared, or a runtime left unpatched. The isolation primitives are sound; the configuration hands the attacker a door and the kernel honors it.

This matters anywhere untrusted or semi-trusted code runs in a container that shares a kernel with other workloads: multi-tenant clusters, CI/CD runners that execute arbitrary build steps, PaaS platforms, and any node where a compromised application pod sits next to sensitive ones. Once an attacker has code execution inside one container (through an application vulnerability, a poisoned dependency, or a malicious build job), the container boundary is the next and often only thing standing between them and the whole node.

• ▸Multi-tenant Kubernetes or orchestrator nodes where one tenant’s pod shares a kernel with another’s.
• ▸CI/CD build runners that execute untrusted pull-request code inside containers.
• ▸Containers granted broad capabilities or host mounts "to make something work" (debugging tools, device access, nested builds).
• ▸Clusters where the container runtime, kernel, or orchestrator components lag on security patches.

Containment is the conjunction of several independent controls, and it is only as strong as the weakest one left in place. Namespaces give the container its own view of processes, mounts, network and users; cgroups bound resource use; Linux capabilities split root’s power into units that can be dropped individually; seccomp filters which syscalls the process may make; and an LSM (AppArmor or SELinux) adds a mandatory policy on top. Remove or weaken any of these and a whole class of escape opens up.

The recurring theme is that the kernel is shared. Anything that lets container-side code talk more directly to that shared kernel — a dangerous capability, a raw device, a writable host filesystem path, a shared PID or network namespace — converts "a process in a box" into "a process with a lever on the host". The escape is the attacker finding and pulling that lever.

Linux capability

A unit of root’s authority (e.g. CAP_SYS_ADMIN, CAP_SYS_PTRACE, CAP_DAC_OVERRIDE). A container should hold only the few it genuinely needs; broad capabilities are the most common escape enabler.

Namespace sharing

Running a container in the host’s PID, network, IPC or user namespace (hostPID, hostNetwork, hostIPC) removes the isolation that namespace provided.

Sensitive host mount

Mounting a host path into the container — the Docker socket, /proc, /, or a device node — so container code can act on the host or the runtime directly.

seccomp / LSM profile

A syscall filter and a mandatory-access-control policy. A container run with seccomp disabled and no AppArmor/SELinux profile exposes the full kernel syscall surface.

The root cause is excessive privilege and weakened isolation granted to the container at creation time, combined with the assumption that "it is in a container, so it is contained". The container runtime faithfully applies whatever the operator requested; if the request includes CAP_SYS_ADMIN, a host mount, or a shared namespace, the runtime is not malfunctioning when the escape works — it is doing exactly what it was told.

A secondary root cause is defaulting to convenience: a device or socket is mounted to make a tool work, a capability is added to silence an error, or `--privileged` is used to stop fighting permissions. Each shortcut trades a hard-to-see security property for an easy-to-see functional one. The defect is the standing configuration, not the moment of exploitation.

1. 1An attacker obtains code execution inside a container — via an application bug, a malicious dependency, or an untrusted CI job they control.
2. 2They enumerate the containment: which capabilities are held, what is mounted, which namespaces are shared, whether seccomp and an LSM profile are active.
3. 3They select a path the configuration left open — for example a mounted container-runtime socket, a writable host filesystem path, or a capability that permits mounting or loading kernel modules.
4. 4They use that path to act on the host: writing to a host-visible file, instructing the runtime to start a new privileged container, or loading code into the shared kernel.
5. 5They now hold execution outside the original container — typically as root on the node — and can read other tenants’ data, pivot to the orchestrator’s credentials, or persist.

Note that steps 3–5 require no kernel zero-day in the common case. A mounted runtime socket or a host-root mount is sufficient on its own; the configuration did the hard part for the attacker.

A synthetic, illustrative pod spec that leaves several escape paths open at once: it shares the host PID namespace, mounts the host root filesystem writable, and grants a broad capability.

synthetic Kubernetes pod — do not deploy; illustrates the flaw
# UNSAFE: multiple isolation boundaries removed at once.
apiVersion: v1
kind: Pod
metadata:
  name: build-helper
spec:
  hostPID: true                 # shares host process namespace
  containers:
    - name: helper
      image: registry.example/internal/build-helper:latest
      securityContext:
        privileged: true         # disables most isolation outright
        capabilities:
          add: ["SYS_ADMIN"]     # permits mount, and much else
      volumeMounts:
        - name: host-root
          mountPath: /host       # host filesystem, writable
  volumes:
    - name: host-root
      hostPath:
        path: /                  # the entire node root
# From inside, writing under /host edits the real node; SYS_ADMIN + hostPID
# give several independent ways to reach host execution.

The hardened version re-establishes every boundary: it drops all capabilities and adds back none it does not need, refuses privilege escalation, runs as a non-root user, keeps the host namespaces unshared, mounts no host paths, and keeps the default seccomp profile. The container becomes a process in a box again.

synthetic Kubernetes pod — least privilege restored
# SAFER: isolation boundaries kept; least privilege.
apiVersion: v1
kind: Pod
metadata:
  name: build-helper
spec:
  # no hostPID / hostNetwork / hostIPC — namespaces stay isolated
  containers:
    - name: helper
      image: registry.example/internal/build-helper:1.4.2  # pinned, not :latest
      securityContext:
        privileged: false
        allowPrivilegeEscalation: false
        runAsNonRoot: true
        runAsUser: 10001
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]          # start from zero; add back only if truly needed
        seccompProfile:
          type: RuntimeDefault    # keep the syscall filter on
      # no hostPath volumes — the node filesystem is not reachable
# If a specific capability is genuinely required, add exactly that one capability
# and document why, rather than reaching for privileged: true.

• ▸Host compromise: code execution as root on the node, outside any container boundary.
• ▸Cross-tenant breach: access to the data and secrets of every other container sharing the node.
• ▸Cluster-wide escalation: theft of the node’s kubelet or cloud credentials, often a stepping stone to control-plane or cloud-account takeover.
• ▸Persistence and lateral movement: the attacker can install host-level implants that survive container restarts and reach the wider network.

Two layers. Configuration review finds the standing exposure before anything runs: scan pod specs, Dockerfiles and compose files for privileged mode, added capabilities, host namespace sharing, hostPath mounts of sensitive paths, and disabled seccomp. This is presence detection — it tells you the door exists, not that anyone walked through it. Runtime detection watches for the escape in progress: unexpected mounts, writes to host paths, child processes appearing in the host PID namespace, or syscalls a workload has no business making. The honest signal is a demonstrated breakout or a concrete reachable path, not merely a flag set to true.

This entry is reference material. ROOTVIEL’s verified, execute-and-prove engine is focused on AI/agentic and Web3 findings, where it composes a candidate attack, runs it in a sandbox, and lets a deterministic verifier settle whether the issue is real. Container escape sits outside that proven surface: ROOTVIEL does not have a verified engine for infrastructure vulnerabilities.

Default to the tightest containment and relax only with a documented reason. The load-bearing idea is least privilege per container, enforced by policy rather than left to each author.

• ▸Preventive: drop ALL capabilities and add back only the specific ones a workload proves it needs; never use privileged mode for application pods.
• ▸Preventive: do not share host namespaces (hostPID/hostNetwork/hostIPC) and do not mount the container-runtime socket, host root, or device nodes into application containers.
• ▸Preventive: run as a non-root user, set a read-only root filesystem, forbid privilege escalation, and keep the default seccomp profile plus an AppArmor/SELinux policy.
• ▸Preventive (design): for untrusted code, use a stronger isolation layer (microVM or user-space kernel sandbox) rather than a shared-kernel container.
• ▸Detective/corrective: enforce the above with an admission controller or policy engine so a non-compliant spec is rejected, and keep runtime and kernel patched.

Verify in an authorized test environment, not by reading the manifest alone. Deploy the hardened workload, confirm from inside the container that the dangerous capabilities are absent, the host namespaces are not shared, and no sensitive host path is mounted, and attempt the specific breakout you were worried about to confirm it now fails. Confirm the admission policy rejects a deliberately non-compliant spec. State the result as "this breakout attempt failed within the tested scope", never as proof of immunity against every escape.

• ▸Reaching for privileged: true (or --privileged) to make a tool work, instead of adding the one capability actually required.
• ▸Mounting the Docker/containerd socket into a container for convenience — that single mount is often a direct, no-exploit escape.
• ▸Treating "it is in a container" as equivalent to "it is isolated", and running untrusted code in a shared-kernel container.
• ▸Hardening one pod while an admission policy still lets any author ship a privileged one.
• ▸Fixing the configuration but leaving the runtime and kernel unpatched, so a CVE reopens the boundary.

Container escape is the sharp end of excess privilege in infrastructure. It is enabled most directly by a privileged container, often chains with an over-permissioned IAM role once the attacker reaches node credentials, and sits beside broken access control as a boundary-crossing failure. The same least-privilege discipline that contains it also limits what a successful escape can then reach.