editorially independent. We may make money when you click on links
to our partners.
Learn More
Recently disclosed runC vulnerabilities are putting containerized environments on high alert, with researchers warning that attackers could potentially break out of Docker and Kubernetes containers, gaining root-level access to the host.
The flaws — tracked as CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881 — affect nearly all versions of runC and hinge on race conditions and mount manipulation that undermine core container isolation controls.
“By using race mount conditions and procfs write redirects, an attacker could gain root access to the host system,” said Sysdig researchers.
Why runC Matters
RunC serves as the low-level engine behind major container platforms, including Docker, Kubernetes, and many managed cloud container services.
Any weakness in runC can ripple across the entire container ecosystem, affecting organizations that rely on these tools for production workloads, CI/CD pipelines, and cloud-native applications.
Inside the runC Vulnerabilities
The three vulnerabilities center on how runC handles masked paths, mount targets, and writes to procfs — all of which can be manipulated under certain race conditions.
CVE-2025-31133 – Abuse of maskedPaths during container start
This flaw arises from runC’s use of /dev/null to mask sensitive host files.
Because runC does not properly verify that /dev/null is legitimate, attackers can swap it with a symlink during initialization.
This allows arbitrary host paths to be bind-mounted into the container, enabling writes to files such as /proc/sys/kernel/core_pattern, a known container-escape vector.
CVE-2025-52565 – Races in /dev/console mount handling
During container setup, runC mounts a pseudo-terminal device to /dev/console.
Attackers who manipulate mount targets using symlinks can redirect this mount before security protections take effect.
This timing vulnerability exposes protected procfs entries, again enabling container escape.
CVE-2025-52881 – Arbitrary /proc write redirection
Perhaps the most dangerous of the three, this vulnerability lets attackers redirect runC’s writes to arbitrary files using shared mount tricks.
Attackers can bypass Linux Security Module labels and force runC to write directly to hazardous locations like /proc/sysrq-trigger, potentially causing system crashes or privilege escalation.
Researchers at Sysdig note that exploiting these flaws typically requires the ability to launch containers with custom mount configurations, making malicious container images and rogue Dockerfiles the most likely attack vectors.
Essential Steps for Container Protection
Organizations aiming to reduce exposure to the runC vulnerabilities should adopt a layered, defense-in-depth strategy for securing container environments.
These steps help improve isolation, detect suspicious activity, and strengthen overall container supply chain security.
- Patch runC to version 1.2.8, 1.3.3, 1.4.0-rc.3, or later, and apply all corresponding vendor updates from platforms like AWS ECS/EKS.
- Enable user namespaces and prefer rootless containers to limit access to sensitive procfs files and reduce the impact of a breakout.
- Restrict privileged operations by disabling privileged mode, removing dangerous Linux capabilities, and blocking custom or hostPath mounts through admission controls.
- Enforce security policies such as AppArmor, SELinux, Seccomp, and Kubernetes Pod Security Standards to constrain filesystem access, syscalls, and mount behavior.
- Monitor for suspicious activity including symlink creation, unusual mount operations, and unexpected writes to /proc.
- Strengthen supply chain security by scanning images, enforcing image signing and verification, and limiting the use of untrusted images or Dockerfiles.
Building true cyber resilience requires going beyond just patching by combining layered controls to protect against emerging threats.
The New Reality of Container Security Threats
These vulnerabilities underscore a broader systemic challenge: as cloud-native environments scale, even foundational components like runC can become single points of failure.
Container escape flaws highlight how attackers increasingly target the runtime layer and supply chain entry points — particularly through untrusted images and CI/CD workflows.
These risks make it clear that securing the container runtime is only one piece of the puzzle, pointing directly to the need for a stronger, more integrated DevSecOps approach across the entire software delivery pipeline.
