Container Escape
Containers are meant to isolate an application from the host and from other containers. Container escape is when an attacker controlling a process inside a container breaks that isolation and reaches the host (or other containers). From an application-level foothold they get host-level reach.
Term
description · examples · notesContainers are meant to isolate an application from the host and from other containers. Container escape is when an attacker controlling a process inside a container breaks that isolation and reaches the host (or other containers). From an application-level foothold they get host-level reach.
Description
How: a misconfigured container ('privileged' mode, host paths mounted in, dangerous capabilities), a kernel vulnerability, or a too-permissive runtime or orchestrator. Once on the host, the attacker reaches every container on it, and often the whole cluster.
The consequence is that an exposed web app in one container — which was meant to be a contained blast radius — becomes a doorway to the entire node: other tenants' data, secrets mounted on the host, the orchestration layer.
Examples
- A small business runs a container in 'privileged' mode for easier setup; a vulnerability in the app inside becomes an entry to the whole server.
- A small factory mounts a host path into a container; from the container the attacker reads and changes host files.
- A distributor hosts multiple clients on the same node; an escape from one container exposes the others' data.
Notes
- A container isn't a secure boundary by itself — it's a boundary only as far as it's well configured.
- A 'privileged' container is usually a sign someone found it easier to switch protection off than to configure it.
Threats
used by 4Threats that use it. Select one to open its page.
Defenses
countered by 5How it is countered. Select one to open its page.