Recently, three high severity vulnerabilities were disclosed in runC, the low-level container runtime used by Docker, containerd, Kubernetes, and other container platforms. By exploiting these vulnerabilities, it is possible to bypass container isolation boundaries and break out of the container to the underlying host.
What is runC?
runC is the low-level container runtime that Docker, containerd, Kubernetes, CRI-O and others rely on to actually create containers and set up their isolation. While it exposes a CLI, its real role is behind the scenes: configuring namespaces, cgroups, mounts, and setting up the container’s filesystem and other interfaces before your container process starts.
Why runC Vulnerabilities Matter for Docker and Kubernetes Security
Because runC is responsible for container isolation, any vulnerability affecting runC potentially affects the security boundary between the isolated container and the underlying host. This is why, for example, any workload running on top of Kubernetes can be affected.
Breaking Down CVE-2025-31133: “Masking” Turns Into Arbitrary Mount Gadget
The OCI runtime specification has a maskedPath feature that is supposed to hide sensitive files and directories (e.g. /proc/kcore, /proc/sysrq-trigger) by mounting something harmless on top. This protects against privileged users in non-user-namespaced being able to write to files or access directories that would provide sensitive information or allow containers to perform destructive or other privileged operations on the host. Files are masked by mounting the container’s /dev/null on top of the masked path.
In vulnerable versions of runC, the issue is that runC didn’t verify that the source of the bind-mount (container’s /dev/null) was a real /dev/null. If an attacker races and swaps it with a symlink to an attacker-controlled path, they could cause runC to bind-mount an arbitrary source path to a path inside the container, which can lead to a container escape.
Breaking Down CVE-2025-52565: /dev/console Bind-Mount Race
This is pretty similar in concept to the above mentioned CVE, but with a different target. runC bind-mounts /dev/pts/$n to /dev/console inside the container for interactive consoles. If an attacker races and swaps it with a symlink to an attacker-controlled path, runC will bind mount whatever that symlink points to.
Since /dev/console bind mount happens before maskedPaths and readonlyPaths security features are applied, the attacker can potentially gain write access, which can lead to a container breakout.
Breaking Down CVE-2025-52881: LSM Bypass & Arbitrary /proc Write Gadgets
This is a more advanced variation of an older procfs/LSM vulnerability CVE–2019-19921. The flaw is in how runC handles writes to a /proc during container setup.
With the right timing and mount tricks, an attacker can potentially redirect these writes to other, more dangerous files such as sysrq-trigger or core-pattern, which could lead to a container escape bypassing LSM label protections.
What Is the Exploitability of These runC Vulnerabilities?
In order to be able to exploit above mentioned vulnerabilities, an attacker would need the ability to start containers with custom mount/runtime configs or to supply Dockerfiles that use custom mounts/clever build tricks via different tactics of a supply chain attack. Such can be achieved via malicious container images or Dockerfiles.
Which runC Versions Are Affected?
CVE-2025-31133
Affected versions: All
Fixed: 1.2.8, 1.3.3, 1.4.0-rc.3, and later
CVE-2025-52565
Affected versions: v1.0.0-rc3 and later
Fixed: 1.2.8, 1.3.3, 1.4.0-rc.3, and later
CVE-2025-52881
Affected versions: All
Fixed: 1.2.8, 1.3.3, 1.4.0-rc.3
Next Steps: How to Patch and Mitigate Vulnerable runC Versions
- If you are running vulnerable versions of runC, upgrade to 1.2.8, 1.3.3, 1.4.0-rc.3 accordingly (or follow with vendor equivalent patches and instructions)
- Verify the sources of container images and Dockerfiles
- Follow security hygiene/good practices:
- Use
user namespacesto map containerrootto an unprivileged user on the host system - Prefer rootless containers when possible
- Run applications as non-root inside the container to minimize risks
- Use
How can Minimus help?
Our team is constantly tracking vulnerabilities that might expose our images and packages to potential risks. As a provider of secure, minimal container images, we ensure that foundational components stay hardened and up to date.
When issues like these runC CVEs are disclosed, we patch and rebuild affected components, making sure that images that are relying on runC are secure from the above mentioned vulnerabilities.
If you want to stay ahead of container-runtime vulnerabilities, explore Minimus images.