Threat Intel

CVE-2022-0492: Linux Cgroups Container Escape (Now Actively Exploited)

Linux kernel cgroups vulnerability diagram showing container namespace boundary breach and privilege escalation path.

Now Being Exploited: A Three-Year-Old Container Escape

A Linux kernel vulnerability that's been public for three years is now being actively exploited in the wild to escape containers and gain root access. CISA added it to their Known Exploited Vulnerabilities (KEV) catalog on June 2, 2026, giving federal agencies until June 5 to patch.

The flaw is in cgroups v1, Linux's resource control and process grouping mechanism. A simple bug in how cgroups validates the release_agent file allows unprivileged users to gain root within containers.

What Cgroups Are (And Why v1 Is the Problem)

Linux cgroups (control groups) let you specify which OS resources a group of processes can use. They're essential for containers—combined with namespaces, cgroups isolate container processes from the host and from each other.

There are two versions:

Cgroups v2: Modern, unified, more secure
Cgroups v1: Legacy, fragmented, vulnerable to CVE-2022-0492

Many production systems still use cgroups v1 for compatibility. That's the attack surface.

How the Exploit Works

The vulnerability is straightforward once you understand cgroups internals:

Step 1: The release_agent File

Cgroups v1 has a notification mechanism. When a cgroup becomes empty (all processes exit), cgroups runs a script called release_agent as root within the cgroup's namespace. This is meant for cleanup tasks.

The release_agent file path is stored at the root of the cgroup hierarchy and should only be writable by root. But the vulnerability allows unprivileged users to modify it.

Step 2: Create a Malicious Script

An attacker creates a script on the host filesystem (or mounts one in a container) with arbitrary commands. This script becomes the new release_agent.

Step 3: Trigger the Notification

The attacker creates a cgroup with a malicious release_agent pointing to their script, then empties the cgroup (by killing all processes in it). When the cgroup becomes empty, the kernel executes the release_agent script as root.

Step 4: Container Escape + Root

The script now runs as root on the host. The attacker has escaped the container and gained root privileges.

Bonus exploitation path: The attacker can also create a new user namespace with admin privileges, then create a cgroup with a malicious release_agent file. Same result.

Why This Matters Now

The vulnerability was disclosed three years ago (2023). Technical details have been publicly available. But in-the-wild exploitation wasn't confirmed until this week when Kaspersky reported it in their blog post on container attack vectors.

Key timeline:

2023: CVE-2022-0492 disclosure, technical details published
June 3, 2026: Kaspersky reports in-the-wild exploitation
June 2, 2026: CISA adds to KEV catalog, urges patching

The fact that a three-year-old vulnerability is suddenly being actively exploited suggests:

Exploit code became public or weaponized recently
Attackers are targeting container environments specifically
This is a known evasion technique in the container attack toolkit

Who's Vulnerable

Direct vulnerability: Any system using cgroups v1 that allows unprivileged user namespace creation.

Container environments: This is the primary attack surface. Containers rely on cgroups for isolation. If cgroups v1 is misconfigured or unpatched, container escape is trivial.

Affected scenarios:

Kubernetes clusters using cgroups v1 (many do by default)
Docker with default cgroup driver (cgroups v1 on older systems)
LXC/LXD containers
Any application using unshare(1) with cgroup isolation

Not vulnerable:

Systems using cgroups v2 only
Systems that disable unprivileged user namespaces
Systems that restrict cgroup access via SELinux or AppArmor

Patch Status

Kernel fix: Available in recent kernel versions. The issue is in the cgroups v1 code path.

Distribution patches:

RHEL/CentOS: Available
Ubuntu: Available
Debian: Available
Alpine: Available (if using affected kernel versions)

Check your kernel version:

uname -r

If you're on a kernel released after mid-2022 (after the initial CVE disclosure), you likely have the patch. If not, update immediately.

Immediate Actions

For Container Environments

Option 1: Upgrade to cgroups v2 (recommended, long-term)

Most modern systems support cgroups v2. Switching is the best long-term fix:

# Check if cgroups v2 is available
grep cgroup2 /proc/filesystems

# If present, enable it at boot
# For systemd: add systemd.unified_cgroup_hierarchy=1 to kernel boot parameters
# RHEL/CentOS 9, Ubuntu 22.04+ support this

Option 2: Patch kernel immediately (short-term)

# Debian/Ubuntu
apt update && apt upgrade linux-image-generic
reboot

# RHEL/CentOS/CloudLinux
dnf update kernel
reboot

# Alpine
apk update && apk upgrade linux-virt
reboot

Option 3: Disable unprivileged namespaces (if you don't need containers)

If you're not running containers, disable unprivileged user namespaces:

# RHEL/CentOS
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-disable-userns.conf
sudo sysctl -p /etc/sysctl.d/99-disable-userns.conf

# Debian/Ubuntu
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-disable-userns.conf
sudo sysctl -p /etc/sysctl.d/99-disable-userns.conf

⚠️ This breaks rootless containers and sandboxing. Only use if you don't need those features.

For Kubernetes

If running Kubernetes:

Patch worker nodes immediately (kernel update + reboot)
Drain pods during maintenance to avoid disruption
Monitor for suspicious pod behavior (processes running as root, escaping the pod sandbox)

Kubernetes uses cgroups for resource limits and isolation. Patching is critical.

For Docker/Container Platforms

Ensure:

Host kernel is patched
Cgroups v2 is enabled if possible
SELinux or AppArmor policies restrict cgroup access (defense in depth)

Detection & Monitoring

Signs of exploitation:

Root processes running outside their containers
Unexpected code execution in the cgroup namespace
Modified release_agent files
Container escape attempts (processes appearing on host from container)

Check for cgroups v1 vulnerabilities:

# Check if cgroups v1 is in use
grep -i cgroup /proc/mounts | head -5

# Output will show either cgroup (v1) or cgroup2 (v2)
# If you see "cgroup " (not cgroup2), you're using v1

Monitor for exploitation:

# Check audit logs for release_agent modifications
grep release_agent /var/log/audit/audit.log

# Check for user namespace creation from containers
grep "namespace" /var/log/audit/audit.log | grep -i "allowed\|denied"

Why Cgroups v1 Still Exists

Cgroups v2 has been available for years and is more secure. But many production systems still use v1 because:

Compatibility: Older applications and tools expect cgroups v1
Adoption lag: Kubernetes and container runtimes took years to support v2
Migration friction: Moving from v1 to v2 requires testing and planning

This is a common pattern in Linux: old, vulnerable code stays around for years because migration is hard.

Real-World Impact

This vulnerability is critical for container environments because:

Container escape is the goal: Attackers want to break out of containers and reach the host
Root privileges are the reward: Once escaped, the attacker has full system access
Three-year latency: A three-year gap between disclosure and active exploitation means many systems remained unpatched thinking the vulnerability "wasn't real"

The fact that Kaspersky is seeing in-the-wild exploitation suggests this is now part of the active threat landscape for container environments.

CISA Timeline

June 2, 2026: CISA added CVE-2022-0492 to the Known Exploited Vulnerabilities (KEV) catalog
Federal agencies: Must patch by June 5, 2026 (3 days)
Everyone else: Should patch immediately (don't wait)

CISA's addition to the KEV catalog signals that this vulnerability is actively weaponized and being used in attacks. Patching is urgent, not optional.

Questions to Ask

Am I running containers? If yes, you're directly at risk.
Which cgroups version? Check grep cgroup /proc/mounts.
Is my kernel patched? Check uname -r against distribution advisories.
Can I upgrade to cgroups v2? This is the best long-term fix.
Are my container images regularly scanned? Attackers may package exploits in compromised images.