Home / Knowledge hub / Container escape
Knowledge hub
Container escape
Breaking out of a container to reach the machine that hosts it.
What it means
A container escape is when code running inside a container gets out of its isolation and acts on the host machine, or on other containers there. The container is meant to be a sealed box. An escape means the box has been opened from the inside.
Containers share the host's kernel, so isolation depends on kernel features and on the settings you gave the container. A weakness in either can be enough. MITRE lists the technique as Escape to Host.
Why it matters
A host usually runs many containers, often from different teams or even different customers. Once someone is on the host, they can read the other containers' files, memory and secrets, and move to other machines in the cluster.
It turns a bug in one application into a problem for everything nearby. An attacker who got in through remote code execution in one service would otherwise be stuck inside that container.
How it shows up
Escapes usually rely on configuration rather than on clever tricks: a privileged container, a mounted Docker socket, a mount of the host's file system, extra Linux capabilities, or a kernel flaw that has not been patched.
Review what each container is allowed to do. Drop capabilities it does not need, do not run as root, block privilege escalation, apply a seccomp profile, and keep the host kernel patched. Sandboxed runtimes add another wall for workloads you trust less.
Questions people ask
Container escape, answered
Is a container escape common?
Real escapes through kernel or runtime flaws are rare and get patched. Escapes through unsafe settings, such as privileged mode or a mounted socket, are far more common and entirely avoidable.
Does running as non-root stop an escape?
It makes many routes harder, but not impossible. Combine it with dropped capabilities, no privilege escalation and a patched kernel.
Are virtual machines safer than containers?
They isolate more strongly because each has its own kernel. Containers are lighter but share one, so settings matter more.
How would we know it happened?
Runtime monitoring can flag odd behaviour, such as a container process touching host paths or starting a shell on the host. Without it, you may learn from the damage.
What should we fix first?
Remove privileged mode, host mounts and the Docker socket from any workload that does not strictly need them.
Sources
Where this comes from
Related
Terms that sit next to this one
Privileged container
A container given near-host powers, so a flaw inside it is a flaw in the host.
Rootless container
A container run as an ordinary user, limiting damage if it is broken into.
seccomp
A Linux feature that limits which system calls a container may make.
Runtime security
Watching containers while they run for behaviour that should never happen.
Lateral movement
Moving from the first thing reached to the things worth taking.
Can a flaw leave its container?
We find the application flaws that give an intruder a first foothold, and prove each one with the request and response. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.