Container escape vulnerabilities discovered in runC container runtime

Three high-severity security vulnerabilities have been discovered in runC, the widely-used container runtime that serves as the reference implementation of the Open Container Initiative (OCI) and powers Docker, Kubernetes, and other containerization platforms. 

The vulnerabilities enable attackers to break through container isolation and achieve full container breakout with root privileges on the host system. 

Vulnerabilities summary:

• CVE-2025-31133 (CVSS score 8.2) - Container escape via 'masked path' abuse due to mount race conditions. RunC uses /dev/null bind-mounts to "mask" sensitive host files through the maskedPaths feature. If an attacker replaces /dev/null with a symbolic link to another procfs file during container initialization, runC can be tricked into bind-mounting an attacker-controlled target with read-write permissions into the container. This enables writes to critical /proc files such as /proc/sys/kernel/core_pattern or /proc/sysrq-trigger, leading to complete container escape or host system denial of service.
• CVE-2025-52565 (CVSS score 8.2) - Container escape with malicious config due to /dev/console mount and related races. This vulnerability targets the /dev/console bind-mount operation during container initialization. Due to insufficient validation when bind-mounting /dev/pts/$n to /dev/console inside the container, an attacker can replace the target path with a symbolic link, causing runC to bind-mount the wrong target. This occurs after pivot_root(2) and provides the attacker with write access to protected procfs paths, enabling container breakout through the same /proc/sys/kernel/core_pattern or /proc/sysrq-trigger exploitation paths as CVE-2025-31133.
• CVE-2025-52881 (CVSS score 8.2) - Container escape and denial of service due to arbitrary write gadgets and procfs write redirects. This flaw is a more sophisticated variant of CVE-2019-19921 and allows attackers to bypass Linux Security Module protections such as SELinux and AppArmor by redirecting writes to procfs files through racing container operations with shared mounts. Attackers can manipulate dangerous system files, effectively neutering LSM labels and enabling writes to host-level procfs, which leads to full host compromise. Research analysis indicates that neither AppArmor nor SELinux can protect against the complete version of this redirected write attack, as the container runtime generally has sufficient privileges to write to arbitrary procfs files.

CVE-2025-31133 Attack example: 
1. Attacker replaces /dev/null with a symlink during container creation ln -sf /proc/sys/kernel/core_pattern /dev/null
2. runC tries to "mask" a sensitive path by bind-mounting /dev/null # But /dev/null is now a symlink, so runC accidentally bind-mounts  # /proc/sys/kernel/core_pattern with WRITE access instead  
3. Attacker writes malicious payload echo "|/tmp/evil_script" > /proc/sys/kernel/core_pattern

Result: When any program crashes, the kernel executes /tmp/evil_script  # with root privileges causing complete container escape

Affected versions of runC:

• CVE-2025-31133 affects all known runC versions
• CVE-2025-52881 affects all known runC versions
• CVE-2025-52565 affects runC versions 1.0.0-rc3 and all later versions through 1.4.0-rc.2

Patched versions:

• runC version 1.2.8 and all later releases
• runC version 1.3.3 and all later releases
• runC version 1.4.0-rc.3 and all later releases

Organizations running containerized environments should plan an update runC to versions 1.2.8, 1.3.3, or 1.4.0-rc.3 or later. 

Major cloud providers including Amazon Web Services (AWS) for Elastic Container Service (ECS) and Elastic Kubernetes Service (EKS) released security updates on November 5, 2025. 

The most effective mitigation is enabling user namespaces for all containers without mapping the host root user into the container's namespace, which blocks most serious aspects of these attacks since the procfs files used for container breakout rely on Unix DAC permissions. 

Rootless containers provide even greater protection by running runC itself as an unprivileged process, significantly limiting the impact scope of any runC vulnerability. 

Organizations should also implement strict container image scanning policies to detect malicious Dockerfiles attempting to exploit these techniques.

Currently, there is no evidence that these vulnerabilities are being actively exploited in the wild, but the combination of widespread runC deployment and the severity of potential impact makes immediate patching critical.