CVE-2025-31133: 
cAdvisor vulnerability analysis and mitigation

CVE-2025-31133 is a container escape vulnerability in runc, the CLI tool for spawning and running containers according to the OCI specification, caused by insufficient verification of bind-mount sources when using the maskedPaths feature. Discovered by Lei Wang (@ssst0n3 from Huawei) and Li Fubang (@lifubang), it was publicly disclosed on November 5, 2025 via a GitHub Security Advisory. Affected versions include runc ≤1.2.7, 1.3.0-rc.1 through 1.3.2, and 1.4.0-rc.1 through 1.4.0-rc.2. It carries a CVSS v3.1 base score of 7.8 (High) and a CVSS v4.0 base score of 7.3 (High) (GitHub Advisory).

The root cause is classified under CWE-61 (UNIX Symbolic Link Following) and CWE-363 (Race Condition Enabling Link Following). When runc applies maskedPaths to files, it bind-mounts the container's /dev/null over the target path to conceal its contents; however, runc failed to verify that the source /dev/null was actually a legitimate character device inode (major 1, minor 3). This enables two attack vectors: (1) an attacker can race to replace /dev/null with a symlink to an attacker-controlled path, causing runc to bind-mount an arbitrary host path into the container (arbitrary mount gadget); and (2) an attacker can delete /dev/null before the bind-mount occurs, causing runc to silently skip the maskedPaths application due to improper ENOENT handling, thereby bypassing path masking entirely. The attack is exploitable via race conditions with other containers sharing mounts, and has been confirmed exploitable using a standard Dockerfile with docker buildx build (GitHub Advisory, Patch Commit).

Successful exploitation can result in host information disclosure (e.g., reading sensitive /proc files like /proc/kcore), host denial of service (e.g., bind-mounting /proc/sysrq-trigger to trigger a kernel panic), or full container escape with root privileges on the host (e.g., reconfiguring /proc/sys/kernel/core_pattern to execute an arbitrary binary as a kernel upcall). The scope is changed — a low-privileged attacker inside a container can compromise the underlying host system, affecting confidentiality, integrity, and availability at the highest level. Downstream environments using Docker, Kubernetes, Podman, and other runc-based container runtimes are all potentially affected (GitHub Advisory).

Multiple public proof-of-concept exploits are available on GitHub, including repositories demonstrating container escape techniques (PoC 1, PoC 2, PoC 3). As of the time of reporting, there is no confirmed evidence of in-the-wild exploitation, and no threat actor attribution has been made. The EPSS score is very low at 0.0001, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires local access with low privileges but involves a race condition (high attack complexity under CVSSv3.1), and requires some degree of control over container spawning (GitHub Advisory).

1. Reconnaissance: Identify a target environment running a vulnerable version of runc (≤1.2.7, 1.3.0-rc.1–1.3.2, or 1.4.0-rc.1–1.4.0-rc.2) via Docker, Kubernetes, or Podman. Confirm the runc version with runc --version or by inspecting container runtime metadata.
2. Gain container access: Obtain low-privileged execution inside a container, or the ability to spawn containers with some control over their configuration (e.g., via a Dockerfile with docker buildx build).
3. Set up shared mount context: Arrange for parallel container execution that shares a mount namespace or /dev bind mount, enabling race condition exploitation against the container's /dev/null.
4. Race to replace /dev/null (Attack 1): In a tight loop, replace the container's /dev/null with a symlink pointing to an attacker-controlled host path (e.g., /proc/sys/kernel/core_pattern) before runc performs the maskedPaths bind-mount. This causes runc to bind-mount the attacker-chosen host path into the container.
5. Exploit the arbitrary mount: With /proc/sys/kernel/core_pattern now accessible and writable inside the container, write a malicious coredump helper path (e.g., |/path/to/malicious/binary). Since kernel upcalls are not namespaced, this binary executes with full host root privileges.
6. Trigger coredump: Cause a process inside the container to crash (e.g., via kill -SIGSEGV $$) to trigger the coredump handler, executing the attacker's binary on the host with root privileges.
7. Alternative (Attack 2 - bypass maskedPaths): Race to delete /dev/null before runc's bind-mount, causing runc to silently skip masking. Then read sensitive host files (e.g., /proc/kcore) that would normally be masked (GitHub Advisory).

• File System: Presence of a symlink at /dev/null inside a container pointing to a host path (e.g., /proc/sys/kernel/core_pattern) instead of a character device (major 1, minor 3); unexpected files or scripts written to host paths accessible from within a container.
• Process: Unexpected processes spawned as root on the host originating from a coredump handler (kernel upcall); processes with host-level privileges that appear to originate from container workloads.
• Logs: Container runtime logs (e.g., Docker daemon, containerd) showing errors related to maskPaths, ENOENT during bind-mount operations, or unexpected mount source paths; audit logs showing bind-mounts of sensitive /proc paths from within container namespaces.
• Network: Unexpected outbound connections from the host system initiated by processes that correlate with container coredump events or container escape activity.
• Kernel/System: Changes to /proc/sys/kernel/core_pattern that reference container-internal paths or unusual binaries; unexpected coredump events on the host system (GitHub Advisory).

Upgrade runc to a patched version: 1.2.8, 1.3.3, or 1.4.0-rc.3 or later. For Microsoft environments, apply updates for CBL2 Kubernetes 1.28.4-19, CBL2 Moby-runc 1.1.9-9, and AZL3 Kubernetes 1.30.10-14. As a workaround, use containers with user namespaces (with host root not mapped into the container's user namespace), which blocks the most severe aspects of the attack since the relevant procfs files use Unix DAC permissions. Additionally, configure containers to run as non-root users with noNewPrivileges enabled, and apply AppArmor profiles (such as Docker's or Podman's default profiles) which can block write access to most /proc and /sys targets. Avoid running untrusted container images from unverified sources (GitHub Advisory).

The vulnerability received significant attention from the security community, with coverage from BleepingComputer, SecurityWeek, CSO Online, TechRadar, and GBHackers highlighting the container escape risk for Docker and Kubernetes environments (BleepingComputer, SecurityWeek). Security researchers from Orca Security and ARMO published technical blogs analyzing the vulnerability alongside two related runc CVEs (CVE-2025-52565 and CVE-2025-52881) (ARMO Blog, Orca Security). The CNCF published a technical overview of the container breakout vulnerabilities, and AWS, Red Hat, SUSE, Ubuntu, and other major vendors issued security advisories and patches. Community discussion on Reddit and Mastodon reflected concern about the broad impact on container infrastructure, with users of platforms like Unraid and TrueNAS actively tracking patch availability.