By ByteBot
Three critical vulnerabilities in runC—the low-level container runtime powering Docker and Kubernetes—allow attackers to break container isolation and gain root access to host systems. Disclosed November 5, 2025, by SUSE engineer Aleksa Sarai, these flaws affect virtually every containerized deployment. All three carry CVSS scores of 7.3, and two affect every version of runC ever released. If you’re running containers in production, you need to patch now.
What’s Affected and How to Patch
The vulnerabilities are tracked as CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881. CVE-2025-31133 and CVE-2025-52881 affect all runC versions. CVE-2025-52565 impacts runC 1.0.0-rc3 and later. The good news: patches shipped the same day as disclosure. Upgrade to runC 1.2.8, 1.3.3, or 1.4.0-rc.3 and later immediately. AWS already pushed updates for ECS and EKS on November 5.
Check your version:
runc --versionIf you’re below 1.2.8, 1.3.3, or 1.4.0-rc.3, you’re vulnerable. Patching is not optional.
How the Container Escape Exploits Work
All three vulnerabilities exploit runC’s handling of mounts and symbolic links during container initialization. The attack is elegant in its simplicity: trick runC into mounting the wrong thing, and you own the host.
CVE-2025-31133 abuses masked path implementations. Attackers replace /dev/null with symlinks targeting critical procfs files like /proc/sys/kernel/core_pattern. When runC blindly bind-mounts these targets as writable, the container escapes to the host.
CVE-2025-52565 exploits a race condition. The /dev/console mount happens before maskedPaths and readonlyPaths protections kick in. Replace /dev/pts/$n with a symlink, and runC grants read-write access to sensitive procfs files.
CVE-2025-52881 is the most sophisticated, bypassing Linux Security Modules entirely. It manipulates /proc/self/attr/ to redirect writes to /proc/sysrq-trigger—instant host crash—or /proc/sys/kernel/core_pattern for full escape.
The delivery mechanism is straightforward: malicious container images or Dockerfiles with custom mount configurations using RUN --mount=... instructions. Trusting container images is like running random executables from the internet—because that’s exactly what it is. In Kubernetes clusters, a compromised kubelet could affect every pod on the node and potentially the entire cluster, according to the CNCF technical overview.
Patching Alone Isn’t Enough: User Namespaces Required
Applying the runC patch stops these specific attacks, but container isolation was never absolute. Defense-in-depth is essential, and that means user namespaces and rootless containers.
User namespaces map container root (UID 0) to an unprivileged user ID on the host. If an attacker escapes the container, they don’t get root on the host—they get a nobody account with no privileges. Docker has supported user namespaces since version 1.10, but it’s not enabled by default. Enable it:
dockerd --userns-remap=defaultRootless containers go further, running the Docker daemon itself as an unprivileged user. Even if the daemon is compromised, the attacker gains no elevated privileges. Rootless mode is available but requires setup:
dockerd-rootless-setuptool.sh installKubernetes v1.33 finally enables user namespaces by default, a major milestone for container security. It only took a few critical CVEs to get there. Podman, which runs rootless by default, recorded zero security vulnerabilities in 2025 compared to Docker’s daemon-based architecture requiring root access. If you’re not running rootless, you’re running scared—and you should be.
Layer on AppArmor or SELinux for additional isolation, and drop all Linux capabilities except those explicitly required. Aqua Security’s analysis makes it clear: rootless containers significantly reduce the attack surface.
Detection and Runtime Security Monitoring
No active exploits have been reported in the wild yet, but the attack vectors are well-documented. Runtime security tools like Falco can detect exploitation attempts by monitoring for suspicious symlink creation over sensitive files. Sysdig provides experimental Falco rules that watch for symlinks targeting /proc/sysrq-trigger or /proc/sys/kernel/core_pattern.
Image vetting in CI/CD pipelines is no longer optional. Assume all container images are potentially malicious until proven otherwise. Runtime security monitoring should be standard practice, not an afterthought.
The Future of Container Security
Container security is shifting from “set and forget” to active defense. These runC vulnerabilities expose a fundamental truth: container isolation is a lie without proper configuration. The industry prioritized convenience over security, and we’re paying for it in CVEs.
This won’t be the last runC vulnerability. Other container runtimes—Youki and crun—reportedly contain similar flaws. The question isn’t if another critical CVE will drop, it’s when.
The lesson is clear: patch immediately, enable user namespaces, adopt rootless containers where feasible, and implement runtime monitoring. Container isolation was never absolute—just convenient. Treat it accordingly.
