TL;DR

• Vulnerability: Three interrelated flaws in the runC runtime exploit race conditions in mount operations to allow Container Escape.

• Affected Versions: runC versions <=1.2.7, <=1.3.2, and <=1.4.0-rc.2.

• Quick Impact: An attacker with low privileges inside the container can escalate privileges to root on the host, resulting in Denial of Service (DoS) or remote code execution (RCE) on the host.

• Immediate Action: Update runC to 1.2.8, 1.3.3, or 1.4.0-rc.3 (or higher) and implement Admission Policies to ensure the use of User Namespaces, rootless containers, and signed images.

Phase 1 — Understanding the CVE

This set of vulnerabilities (CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881) affects runc, the component that runs containers according to the OCI (Open Container Initiative) specification. The crux of the issue lies in race conditions exploited during the container's setup phase, specifically when handling special file mounts.

The bug occurs because runc fails to verify the integrity of the target of a bind mount at a critical moment. For example, in CVE-2025-31133, runc uses the container's /dev/null to obscure sensitive paths from the host. If an attacker replaces /dev/null with a symlink to a controlled path during the mount window, runc performs an arbitrary bind mount, turning the operation into an Arbitrary Mount Target [3].

Phase 2 — Attack Surface and Exploitation

Who can exploit?

The attack is local and requires the attacker to have low privileges inside the container. It is not a network attack (non-auth), but rather a privilege escalation attack from already compromised or misconfigured containers. Exploitation depends on the ability to manipulate the container's filesystem during the initialization phase, leveraging the race condition.

Practical scenarios in Kubernetes

In Kubernetes environments, the risk is amplified:

• Privileged Pods: Pods running with privileged: true or with elevated capabilities are easy targets.

• Weak Admission Policies: The absence of Admission Policies that restrict the execution of pods as root or that allow privilege escalation increases the attack surface.

• Lateral Movement: After escaping, the attacker can access the Kubernetes node, steal secrets (service tokens), and move laterally through the infrastructure.

Do I need to worry if I use “Managed” Kubernetes?

Yes, but it depends on the cloud provider to deliver the update. However, do not forget that it is necessary to update not only the control plane; the nodes also need to be updated.

Amazon and Google are already aware and releasing updates for their nodes; it's time for a rollout, folks!

Here are the reports from each of them:

AWS - https://aws.amazon.com/security/security-bulletins/rss/aws-2025-024/

GCP - https://docs.cloud.google.com/release-notes

Azure - Not yet informed, follow here for the security feed

Phase 3 — Fixing and Containing

Update now!

The definitive fix is updating the runc runtime.

• Fixed Versions: runc 1.2.8, 1.3.3, and 1.4.0-rc.3 (or higher).

• Action: Immediately update containerd, CRI-O, or any other component that uses runc in your environment. Refer to your distribution vendor's release notes (Red Hat, Ubuntu, SUSE, etc.) for specific packages.

If immediate updating is not possible, implement the following containment policies:

Container Hardening (Admission Policies)

Use ValidatingAdmissionPolicy (with CEL) or tools like Kyverno/Gatekeeper to enforce security policies in the cluster.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: runc-cve-mitigation
spec:
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE","UPDATE"]
      resources: ["pods"]
  validations:
  - expression: "has(object.spec.securityContext) && object.spec.securityContext.runAsNonRoot == true"
    message: "Pods should run as non-root to mitigate privilege escalation."
  - expression: "object.spec.containers.all(c, has(c.securityContext) && c.securityContext.privileged != true && c.securityContext.allowPrivilegeEscalation != true)"
    message: "Privileged and allowPrivilegeEscalation must be disabled."
  - expression: "has(object.spec.securityContext) && object.spec.securityContext.seccompProfile.type == 'RuntimeDefault'"
    message: "Enforce seccompProfile as RuntimeDefault or tighter."

NetworkPolicies

Restrict lateral movement after a potential escape. A restrictive egress NetworkPolicy is crucial.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: my-vulnerable-app
spec:
  podSelector:
    matchLabels: { app: my-vulnerable-app }
  policyTypes: [Egress]
  # Block all egress traffic except what is strictly required
  egress:
  - to:
    - ipBlock:
        # Allow traffic only to the API server (example)
        cidr: 10.0.0.0/24 
    ports:
    - protocol: TCP
      port: 443

Supply Chain Hardening

The risk assessment should include the source of the images.

As they are the attack vector, having control over your images is the first step for protection; other vulnerabilities can be exploited to gain access to your application and then exploit this runC vulnerability to gain access to the entire system.

Use secure base images with a minimal attack surface. Start now at app.quor.dev 

Detection and Response

Indicators in logs

The successful exploitation of a container escape via core_pattern may leave traces in the host or the container runtime logs, especially attempts to write to sensitive /proc files.

Falco: Behavioral Detection of Container Escape

Falco, the runtime security monitor from Sysdig, is an essential tool for detecting the exploitation of these runC CVEs, as it operates at the system call (syscalls) level and kernel events, monitoring actual container behavior, rather than just vulnerability signatures. Successful exploitation of these flaws, culminating in a container escape and privilege escalation, invariably involves highly suspicious actions at the host system level. Specifically, Falco can be configured with rules to trigger immediate alerts upon detecting attempts to write to sensitive host files, such as /proc/sys/kernel/core_pattern or /proc/sysrq-trigger, which are the ultimate attack targets exploited by CVE-2025-31133 and CVE-2025-52565. By correlating the process identity (which should be isolated in the container) with the manipulation of critical host files, Falco provides a layer of behavioral defense that transcends the need for immediate patches.

In addition to detecting the final attack, Falco is crucial for identifying attempts to manipulate device files and symlinks that precede escalation. Specific rules can monitor access or creation of symlinks in paths like /dev/null or /dev/console by processes that should not interact with these files in non-standard ways, especially if the process is running with root privileges inside the container. Falco's ability to inspect the context of the container (such as namespaces and capabilities) and the host context simultaneously allows it to differentiate legitimate runtime behavior from malicious activity of a compromised container. Thus, even if CVE-2025-52881 bypasses label-based security policies (like SELinux/AppArmor), Falco still detects the behavioral anomaly at the kernel level, providing the necessary visibility for incident response.

Loki/LogQL Queries

Monitor logs from the runtime (containerd, crio) or the kernel for unusual mount or write activities in sensitive paths.

# 1. Attempts to write to sensitive procfs files (after the escape)

{job="kubelet"} |~ "write to /proc/sys/kernel/core_pattern"

# 2. Security logs (auditd) indicating manipulation of symlinks in /dev

{job="auditd"} |~ "SYMLINK.*(/dev/null|/dev/console)"

Response Steps

1. Isolate: Isolate the compromised node and remove all non-essential pods.

2. Collect Artifacts: Collect logs from the runtime, kernel logs, and the filesystem state of the container and host for forensic assessment.

3. Revoke Credentials: Immediately revoke any ServiceAccounts or API keys that the compromised container may have accessed.

4. Revalidate Integrity: Check the integrity of runc and other critical binaries on the host.

Summary Risk Matrix

Quick Checklist

• Update runC to version 1.2.8, 1.3.3, or 1.4.0-rc.3 (or higher).

• Implement Admission Policies to enforce runAsNonRoot: true.

• Implement Admission Policies to disable privileged: true and allowPrivilegeEscalation: true.

• Configure pods to use User Namespaces whenever possible.

•  Adopt rootless containers as a security standard.

• Review egress NetworkPolicies to limit lateral movement.

•  Monitor runtime and auditd logs for attempts to manipulate mounts or write to /proc.
  
  

References

1. Ubuntu. CVE-2025-31133: https://ubuntu.com/security/CVE-2025-31133

2. Red Hat Customer Portal. CVE-2025-52565: https://access.redhat.com/security/cve/cve-2025-52565

3. GitHub. container escape via "masked path" abuse due to mount race conditions: https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2

4. Red Hat Customer Portal. CVE-2025-52881: https://access.redhat.com/security/cve/cve-2025-52881