By ByteBot
Three critical vulnerabilities in runC — the low-level container runtime underneath Docker, Kubernetes, containerd, and Podman — let attackers break out of container isolation and gain root access on the host. Disclosed in November 2025 and actively exploited as of June 2026, CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881 affect every runC version back to 1.0.0-rc3. The fix is available. If you run containers, patch now.
runC Is the Floor, Not the Wall
Most developers never interact with runC directly, which is exactly what makes this dangerous. runC is the OCI-compliant runtime that executes every container you start — it handles namespaces, cgroups, and the mount setup that is supposed to keep container processes away from the host. Docker uses it. containerd uses it. Kubernetes uses it through CRI. Podman uses it. When runC has a container escape vulnerability, the isolation guarantee that the entire container model is built on collapses.
The attacker does not end up with access to a container. They end up with root on the host node. Every workload on that host is now compromised.
The Three CVEs, Explained
All three vulnerabilities target the same weak point: the sequential mount setup phase that runs before runC applies its security policies. The timing gap between mount operations and protection enforcement is where attackers get in.
CVE-2025-31133 (CVSS 7.3) exploits how runC implements “masked paths.” The runtime bind-mounts /dev/null over sensitive host files to hide them from container processes. The problem: runC did not verify that the container’s /dev/null is an actual /dev/null inode. An attacker replaces it with a symlink to an arbitrary host path. runC then bind-mounts that path as read-write inside the container, handing the attacker write access to kernel parameters like /proc/sysrq-trigger.
CVE-2025-52565 (High) targets /dev/console. runC bind-mounts /dev/pts/$n to /dev/console before masked paths and read-only paths are applied. By replacing /dev/pts/$n with a symlink, an attacker redirects that mount to any target — including /proc/sys/kernel/core_pattern, the file that controls what the kernel executes when any process crashes. Write there, and you control arbitrary code execution on the host.
CVE-2025-52881 (High) is the most sophisticated of the three. It abuses race conditions with shared mounts to redirect runC’s own writes to /proc toward attacker-controlled locations, bypassing Linux Security Modules in the process. The practical outcome is the same: arbitrary write to /proc/sysrq-trigger for a denial of service, or /proc/sys/kernel/core_pattern for a full breakout.
Who Is Actually at Risk
To exploit these vulnerabilities, an attacker needs the ability to start a container with custom mount configurations. That sounds narrow. It is not. The delivery vectors include malicious container images, compromised base images, and untrusted Dockerfiles — all of which appear constantly in CI/CD pipelines, development environments, and multi-tenant Kubernetes clusters.
If your platform runs containers built from user-submitted images, or if your CI/CD pipeline runs arbitrary build steps, you are in the high-risk category. Shared Kubernetes clusters where multiple teams deploy workloads are particularly exposed: one team’s bad image breaks the host for everyone.
Patch Commands
Safe versions: runC 1.2.8, 1.3.3, or 1.4.0-rc.3 and later. containerd 1.6.39+ or 1.7.28-2+ includes the fix. Docker Desktop ships runC 1.3.5 in its latest June 2026 release. For managed Kubernetes, GKE, EKS, and AKS all issued advisories — check your node pool image versions and trigger a node upgrade if you are on images predating November 2025.
Check your current version:
# Check runC version via Docker
docker version | grep -i runc
# Check standalone
runc --version
# Check Kubernetes node runtimes
kubectl get nodes -o custom-columns=NODE:.metadata.name,RUNTIME:.status.nodeInfo.containerRuntimeVersionUpgrade on Debian/Ubuntu:
sudo apt-get update && sudo apt-get install --only-upgrade docker-ce docker-ce-cli containerd.ioUpgrade on RHEL/Fedora:
sudo dnf update docker-ce docker-ce-cli containerd.ioRed Hat users: apply RHSA-2025:19927 and subsequent errata. The CNCF technical breakdown of the mount phase timing issue is worth reading if you manage infrastructure.
Patching Is Not the Full Story
Update runC. That is not optional. But the deeper lesson from these CVEs is that container isolation is a stack, not a single guarantee. Patching the runtime removes the immediate attack surface, but the security posture that made it matter — running untrusted images, skipping pod security admission, allowing privileged containers — stays until you fix it.
Use read-only root filesystems where possible. Apply AppArmor or seccomp profiles to production workloads. Pin image digests, not tags. If you run AI agents in containers, the risk compounds further: a compromised agent that escapes its container reaches the host directly. The Sysdig analysis added Falco detection signatures for exploitation attempts — worth deploying if Falco is already in your cluster.
Container isolation is only as strong as the runtime enforcing it. Right now, if that runtime has not been patched, it is not strong at all.
