Critical runC Flaws Let Hackers Escape Docker Containers

▼ Summary
– Three vulnerabilities (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881) in runC could allow attackers to bypass container isolation and gain root access to the host system.
– These flaws were disclosed by SUSE engineer Aleksa Sarai and affect the universal container runtime used by Docker and Kubernetes.
– CVE-2025-31133 and CVE-2025-52881 impact all runC versions, while CVE-2025-52565 affects versions 1.0.0-rc3 and later, with fixes available in newer releases.
– Exploitation requires starting containers with custom mount configurations, but there are currently no reports of active exploitation.
– Mitigations include using user namespaces, rootless containers, and monitoring for suspicious symlink behavior to detect and prevent attacks.
A set of three critical vulnerabilities discovered in the runC container runtime poses a serious threat, potentially allowing attackers to break out of Docker and Kubernetes containers and gain unauthorized root access to the underlying host system. These security flaws, identified as CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881, were reported by SUSE software engineer and Open Container Initiative board member Aleksa Sarai. The runC tool is a fundamental component, serving as the universal container runtime and the OCI reference implementation that handles low-level operations for creating container processes, setting up namespaces, and managing mounts and cgroups.
An attacker successfully exploiting these vulnerabilities could achieve write access to the host system with root-level privileges, effectively bypassing the container’s isolation safeguards. The first flaw, CVE-2025-31133, involves the way runC uses /dev/null bind-mounts to hide sensitive host files. If a malicious actor replaces /dev/null with a symbolic link during container initialization, the system might mistakenly mount a target controlled by the attacker with read-write permissions into the container. This mistake can enable writes to the /proc filesystem and lead to a full container escape.
The second issue, CVE-2025-52565, concerns the /dev/console bind mount. Through timing attacks or symbolic link manipulation, an attacker can redirect this mount so that runC attaches an unexpected and unprotected target into the container before security measures are fully applied. This action again provides writable access to critical entries in the procfs, creating another pathway for breakout. The third vulnerability, CVE-2025-52881, tricks runC into performing writes to /proc that are then redirected to locations an attacker controls. This method can bypass Linux Security Module relabeling protections in certain scenarios, transforming ordinary runC write operations into arbitrary writes to dangerous system files such as /proc/sysrq-trigger.
CVE-2025-31133 and CVE-2025-52881 impact every version of runC, while CVE-2025-52565 affects runC versions starting from 1.0.0-rc3 and newer. Patches addressing these security holes are now available in runC versions 1.2.8, 1.3.3, 1.4.0-rc.3, and all subsequent releases.
According to analysis from cloud security firm Sysdig, exploiting these three vulnerabilities requires the capability to start containers using custom mount configurations. An attacker could achieve this prerequisite through the use of malicious container images or specially crafted Dockerfiles. To date, security researchers have not observed any active exploitation of these flaws in real-world attacks.
Sysdig’s advisory this week indicates that attempts to leverage any of these three security issues can be identified by monitoring for suspicious symbolic link activities. The developers of runC have also recommended specific mitigation steps. A key action involves activating user namespaces for all containers while ensuring the host’s root user is not mapped into the container’s namespace. This defensive measure should block crucial stages of the attack by leveraging Unix Discretionary Access Control permissions, which would prevent users within the namespace from accessing the relevant host files.
Additionally, Sysdig advises using rootless containers wherever feasible to minimize the potential impact and damage should a vulnerability be successfully exploited.
(Source: Bleeping Computer)




