Within 24 hours, three new high-severity vulnerabilities were disclosed in runc, the low-level runtime that underpins most container platforms, including Docker, containerd, Kubernetes, and nearly every major cloud provider’s managed Kubernetes service. These vulnerabilities (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881) allow a malicious container image to break out of the container boundary and affect the host machine directly.

While the attacks require a specially crafted container image and, in some cases, elevated privileges inside the container, the impact is serious: host compromise or denial of service. This disclosure reinforces a recurring truth in cloud security: the container boundary is not a security boundary by itself. Strong supply-chain controls and runtime detection are critical.

What Is runc and Why Does It Matter?

Most container users have never interacted with runc directly, but it is everywhere.

runc is the reference implementation of the Open Container Initiative (OCI) runtime specification. It is the component responsible for creating containerized processes: configuring kernel namespaces, cgroups, mounts, and process isolation. This enables the creation of containers on Linux machines.

If you run:

• Docker
• Kubernetes
• containerd
• CRI-O
• or any managed Kubernetes like EKS, AKS, or GKE

… on Linux hosts, you are using runc under the hood.

When a vulnerability affects runc, it affects the foundation of nearly all containerized workloads.

The Initial Attack Vector: A Malicious or Compromised Image

The attack begins with a malicious container image, either:

• crafted intentionally by an attacker, or
• unintentionally modified through a supply-chain compromise during build, distribution, or storage.

The attacker does not need to exploit a kernel bug. Instead, they exploit how runc handles mounts and special files during container startup. By combining symlinks, bind mounts, and some timing tricks, the attacker convinces runc to write to the host’s /proc filesystem instead of the container’s view of it.

This is where the real danger begins.

What an Attacker Can Achieve

/proc is a virtual filesystem used by Linux to expose and control kernel behavior. Containers should see their own “copy” of /proc, separate from the host.  If a malicious container can write to specific /proc files of the host, it can:

Host Target	Result
/proc/sys/kernel/core_pattern	Run arbitrary commands on the host whenever any process crashes
/proc/sysrq-trigger	Force a system reboot or crash immediate denial of service
/proc/sys/* settings	Modify kernel-level system behavior, potentially weakening security

In practical terms, the attacker could:

• Gain execution on the host
• Cause a full cluster outage
• Maintain persistence beyond container lifecycle

This is a container escape, achieved without touching the kernel or hypervisor. The attacker is simply abusing runc’s trust that the container filesystem is isolated which, under these conditions, it is not.

How to Mitigate (and What Cloud Users Need to Know)

If You Manage Your Own Kubernetes Nodes

Update runc to a patched version:

• runc v1.4.0-rc.3 or later
• or your distribution’s equivalent (e.g., from Docker or containerd release channels)

Restart container engines after updating:

systemctl restart docker
# or
systemctl restart containerd

If You Use Managed Kubernetes (EKS / AKS / GKE)

Provider	Status / Action
AWS EKS	Check AWS Security Bulletin: https://aws.amazon.com/security/security-bulletins/rss/aws-2025-024/
Azure AKS	Node base images will be patched; users must reimage or rotate nodes.See security bulletins here:https://learn.microsoft.com/en-us/azure/aks/security-bulletins/overview
Google GKE	Look for security release channels and perform node pool upgrades.https://docs.cloud.google.com/release-notes

In all managed Kubernetes cases:

Upgrading the control-plane alone is not enough — worker nodes must be refreshed.

Improving Overall Security Posture

This event highlights a long-standing security reality:

If a container is running untrusted code, assume it can escape under the right conditions.

To reduce exposure:

1. Don’t Run Untrusted or Unsigned Container Images

Use:

• Image signing (e.g., Cosign, Sigstore)
• Policy enforcement (Gatekeeper / Kyverno)
• Private registries

2. Implement Runtime Threat Detection

Even with patches and signing, supply-chain compromise is always possible. A zero-day in a base image, a compromised build step, or a malicious dependency can bypass traditional controls.

A runtime security platform like ARMO detects:

• Unexpected writes to /proc
• Privilege escalation attempts
• Abnormal mount operations
• Behavior inconsistent with expected container profiles

These are exactly the signals triggered in the runc exploit chain.

3. Employ Zero-Trust Workload Identity

Tie behaviors to workloads, not IPs or nodes.

Conclusion

The new runc vulnerabilities are not just another set of CVEs—they are a reminder that containerization does not equal security. The isolation boundary is thin, and attackers are creative.

To stay secure:

• Patch runc
• Rotate your Kubernetes nodes
• Avoid untrusted images
• And most importantly, monitor what workloads actually do at runtime

With ARMO, organizations gain continuous detection and response for container and cloud-native environments allowing them to identify supply-chain attacks, privilege escalation attempts, and container escapes in real time.