runc Container Breakouts
When the Container Boundary Becomes the Attack Surface
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.
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.
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:
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:
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:
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.
↓
Pod X executed process Y
↓
Pod X made network connection Z
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.