runc Container Breakouts

When the Container Boundary Becomes the Attack Surface

AFFECTED COMPONENT
runc
VULNERABILITIES
CVE-2025-31133, CVE-2025-52565, CVE-2025-52881
ASSESSMENT
Critical runtime-security significance

Executive Summary

In November 2025, the Open Container Initiative disclosed three high-severity vulnerabilities affecting runc. The vulnerabilities allowed attackers to manipulate /proc through different mechanisms and ultimately achieve full container escape under affected conditions.

The Architectural Threat

runc is a fundamental component of the Linux container ecosystem, utilized directly beneath container orchestration platforms like Kubernetes. The importance of this incident is profoundly architectural: The security boundary between a container and the host ultimately depends entirely on low-level runtime behavior.

Container Architecture

A vulnerability in runc directly affects the isolation boundary that Kubernetes assumes is intact.

THE CONTAINER STACK
KUBERNETES
↓
CONTAINER RUNTIME
↓
runc
↓
LINUX NAMESPACES
↓
LINUX KERNEL
↓
HOST

CVE-2025-31133: Masked Path Manipulation

CVE-2025-31133 specifically involved the mishandling of masked paths. During container setup, runc can bind-mount /dev/null over paths that need to be intentionally masked from the container.

The vulnerability allowed an attacker to replace /dev/null with a symlink pointing to another /proc file. runc could then unknowingly bind-mount the symlink target read-write into the container.

runc expects:
/dev/null
→
masked target
Attacker manipulates:
/dev/null
→
symlink
→
/proc/...

Why /proc Matters

Linux /proc is not simply a collection of ordinary files. It provides direct, highly sensitive interfaces into active kernel and process state. Consequently:

/proc ↓ kernel state ↓ system behavior

Manipulating certain procfs interfaces can trigger severe consequences entirely outside the container namespace. The Openwall disclosure specifically identified /proc/sys/kernel/core_pattern as one critical path that could facilitate escape, because core-dump helpers execute outside the affected namespace with full host privileges.

The Vulnerability Mechanism

Although the three vulnerabilities used different mechanical triggers, they shared the exact same fundamental outcome:

Container
→
runc weakness
→
procfs manipulation
→
isolation bypass
→
HOST COMPROMISE

Analyst Assessment

This class of threat is fundamentally different from a Kubernetes API attack. The attacker does not necessarily need a Kubernetes administrator account or cluster-admin RBAC permissions. The target is the physical container isolation mechanism itself.

Kubernetes security possesses multiple layers. Compromise at a lower layer can completely bypass logical controls implemented above it:

Kubernetes API
↓
Pod Security Policies
↓
Container Definition
↓ (Bypass occurs here)
Container Runtime (runc)
↓
Linux Kernel

Opsonance Point of View

This incident is perhaps the most heavily aligned threat architecture for Opsonance's low-level runtime-security thesis. The attack exists precisely at the boundary: Container ↕ Linux runtime ↕ Kernel ↕ Host.

TRADITIONAL TELEMETRY
Pod X exists
↓
Pod X executed process Y
↓
Pod X made network connection Z
OPSONANCE TELEMETRY
runtime primitives
↓
procfs interaction
↓
kernel behavior
↓
host effect

Opsonance's emphasis on Linux runtime visibility and continuous kernel-level enforcement is directly relevant to mitigating this class of attack. Container security ultimately depends on the absolute integrity of the runtime enforcing that container's isolation.

Key Finding

CONCLUSION

The runc vulnerabilities demonstrate that Kubernetes isolation is not an absolute, impenetrable security boundary. The container boundary ultimately rests entirely on lower-level runtime and kernel primitives.

References