Three critical vulnerabilities in the OCI reference runtime runC—widely used by Docker, containerd, CRI‑O, and Kubernetes—could let attackers bypass container isolation and write to the host filesystem as root. Tracked as CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881, the issues undermine one of the core trust boundaries in cloud‑native environments.
What happened: three CVEs in the runC container runtime
The flaws were disclosed by Aleksa Sarai of SUSE, a member of the Open Container Initiative (OCI). runC is the reference implementation of the OCI Runtime Specification, responsible for low‑level container lifecycle operations: process creation and namespaces, filesystem mounts, and cgroups configuration. Because higher‑level platforms embed runC, a single runtime defect can propagate across many container engines and Kubernetes clusters.
Affected versions and available patches
According to the advisory, the first and third vulnerabilities affect all runC versions, while the second applies to builds since 1.0.0‑rc3. Fixes are available in runC 1.2.8, 1.3.3, and 1.4.0‑rc.3 (and newer). Administrators should update through their Linux distribution or container platform to ensure the patched runtime is deployed cluster‑wide.
Impact and realistic attack scenarios
Successful exploitation enables host‑level writes with root privileges from within a container—an effective container escape. In practice, this can allow tampering with binaries, service configurations, or node agents, leading to node compromise and lateral movement across the cluster.
Researchers note that exploitation typically requires the ability to launch containers with custom mount configurations. Attackers can achieve this via malicious images and crafted Dockerfiles that combine risky mount options. The risk is substantially higher where operators allow privileged containers, hostPath mounts, excessive Linux capabilities (notably CAP_SYS_ADMIN), or other policy gaps.
Technically, many container‑escape chains abuse symlink races and mount behavior to redirect writes outside the container’s root filesystem (TOCTOU patterns are common). While details vary per CVE, the defensive takeaway is consistent: untrusted mount flexibility plus host privileges creates exploitable paths.
Telemetry and signs of exploitation
At publication time, there were no confirmed reports of in‑the‑wild exploitation. Defenders should monitor for:
- Unusual symlink creation and traversal within writable paths.
- Anomalous mount operations or bind mounts targeting unexpected directories.
- Suspicious file copy actions between container and host contexts.
Mitigation for Docker, containerd, and Kubernetes
1) Patch immediately. Upgrade runC to 1.2.8/1.3.3/1.4.0‑rc.3 or newer and verify that Docker Engine, containerd, CRI‑O, and Kubernetes distributions pick up the patched runtime.
2) Enable user namespaces by default. Mapping container root to an unprivileged host UID blocks many host write paths even if a breakout occurs. This is a practical defense‑in‑depth layer supported broadly by modern kernels.
3) Prefer rootless containers. When feasible, run in rootless mode to confine impact. See Docker Rootless for setup guidance.
4) Constrain risky policies. Avoid privileged pods; restrict or gate hostPath and custom mount options; drop extraneous capabilities (especially CAP_SYS_ADMIN); and use read‑only root filesystems where possible. In Kubernetes, enforce Pod Security Admission, apply seccomp profiles and AppArmor profiles to minimize syscall and filesystem attack surface.
5) Strengthen observability and supply chain controls. Enable EDR/runtime security rules for symlink abuse and nonstandard mounts. Only run signed images and validate provenance with SBOMs (e.g., SPDX) and artifact signing (e.g., Sigstore Cosign).
Why it matters for cloud‑native platforms
Because runC underpins most container platforms, vulnerabilities have a systemic effect. A well‑known precedent is CVE‑2019‑5736, which drove widespread adoption of stricter privilege policies and runtime hardening. The current CVEs again underscore that least privilege, guarded mounts, and continuous runtime monitoring are essential in Kubernetes and CI/CD pipelines.
Organizations should act now: deploy patched runC builds, enable user namespaces, adopt rootless where practical, and tighten admission and runtime policies. Rapid remediation and policy hygiene materially reduce the chances of a successful container escape and follow‑on compromise across production clusters.
