CVE-2022-0492 Container Escape: Fix This Actively Exploited Linux cgroups Flaw Now

A four-year-old Linux kernel bug just landed on the CISA Known Exploited Vulnerabilities catalog — and that means attackers are using it right now in production environments. CVE-2022-0492 container escape is a logical flaw in the cgroups v1 release_agent mechanism. Specifically, an attacker inside a container writes an arbitrary executable path to that file, triggers the cgroup to empty, and the kernel runs the payload as root on the host. No memory corruption. No race condition required. Because it is a clean logic bug, it works consistently on the first attempt. Docker, Kubernetes, and LXC environments on cgroups v1 are all directly exposed. CISA set the federal remediation deadline at June 5, 2026. If your container infrastructure is still on cgroups v1, this post walks you through everything you need to fix it.

What Is CVE-2022-0492?

The vulnerability lives in kernel/cgroup/cgroup-v1.c, inside the cgroup_release_agent_write() function. Specifically, the cgroups v1 subsystem includes a feature called release_agent: when a control group becomes empty, the kernel executes a user-specified cleanup program. While the intent is legitimate, the implementation has a serious flaw.

A missing capability check in the initial user namespace is the root cause. Because of that gap, an attacker who can write to /sys/fs/cgroup/release_agent from inside a container can set it to any executable path on the host. When the targeted cgroup empties, the kernel runs that path as root on the host system. The flaw maps to CWE-287 (Improper Authentication) and CWE-862 (Missing Authorization). Since it is a logic error in access control rather than a memory corruption bug, exploitation is deterministic and reliable — no timing window required.

Why Is a 2022 CVE Being Actively Exploited in 2026?

The kernel patch landed in March 2022, and every major Linux distro shipped the fix that same year. So on modern Ubuntu, RHEL, AlmaLinux, and Debian systems running current kernels, this flaw is already closed. However, production environments are rarely clean. They contain kernels that were deployed and never updated, embedded Linux systems that vendors stopped maintaining years ago, and container hosts built from old cloud AMIs that drifted out of patch cycles.

Beyond that, many Kubernetes clusters have a current control plane but worker node kernels that are years out of date. Additionally, IoT devices running Linux 4.x typically never receive another patch. Because of this gap between what is patched and what is actually running, attackers found a significant population of vulnerable systems worth targeting. Since the container-escape capability turns a low-privilege foothold into full host root access, this CVE is especially valuable for lateral movement through cloud environments after any initial compromise.

Check If You Are Exposed Right Now

Three conditions must all be true simultaneously for the attack path to be reachable. Run these checks on every Linux host that runs containers:

# CHECK 1: What cgroup version is active?
stat -fc %T /sys/fs/cgroup/
# cgroup2fs = cgroups v2 only -- NOT vulnerable via this path
# tmpfs     = cgroups v1 active -- investigate further

# Confirm v1 mount explicitly
mount | grep 'type cgroup '
# Any output means cgroups v1 is mounted

# CHECK 2: Is release_agent writable from inside a container?
# Run this FROM INSIDE a running container
ls -la /sys/fs/cgroup/release_agent 2>/dev/null
cat /sys/fs/cgroup/release_agent 2>/dev/null

# CHECK 3: Kernel version -- patch landed March 2022
uname -r
# Ubuntu: unpatched below 5.4.0-104, 5.13.0-37, 5.15.0-25
# RHEL/CentOS 8: unpatched below kernel-4.18.0-372
# Debian: unpatched below 5.10.103-1

# FULL AUDIT: list all release_agent files on the host
find /sys/fs/cgroup -name release_agent 2>/dev/null | \
  while read f; do echo "$f: $(cat $f 2>/dev/null)"; done

If cgroups v1 is mounted and your kernel is below the patch threshold, the system is vulnerable. Even on a patched kernel, though, migrating to cgroups v2 is the correct long-term move — because it removes the entire v1 attack surface permanently.

Check Your Container Runtime Configuration

# Docker -- confirm cgroup version in use
docker info 2>/dev/null | grep -i cgroup
# Cgroup Version: 2 = safe
# Cgroup Version: 1 = verify kernel is patched

# Identify any privileged containers running (highest risk)
docker ps -q | xargs -I{} docker inspect {} \
  --format '{{.Name}} privileged={{.HostConfig.Privileged}}' 2>/dev/null

# Kubernetes -- check kernel version on every worker node
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kernelVersion}{"\n"}{end}' 2>/dev/null
cat /var/lib/kubelet/config.yaml 2>/dev/null | grep cgroupDriver

# Podman -- confirm cgroup mode
podman info 2>/dev/null | grep -A3 -i cgroup

Immediate Mitigations Without a Reboot

If you cannot patch or migrate immediately, the following steps break the attack chain right now — no restart needed on any of them.

Option 1: Clear and Block release_agent

# Clear all release_agent entries on the host immediately
find /sys/fs/cgroup -name release_agent 2>/dev/null | \
  while read f; do
    echo '' > "$f" 2>/dev/null && echo "Cleared: $f" || echo "Cannot clear: $f"
  done

# Make the block persistent via a Docker systemd drop-in
mkdir -p /etc/systemd/system/docker.service.d/
cat > /etc/systemd/system/docker.service.d/no-release-agent.conf << 'DREOF'
[Service]
ExecStartPre=/bin/sh -c 'find /sys/fs/cgroup -name release_agent -exec sh -c "echo > {}" \;'
DREOF
systemctl daemon-reload && systemctl restart docker

Option 2: Enforce SELinux or AppArmor

When either SELinux or AppArmor is enforcing, the container escape path for CVE-2022-0492 is blocked even on an unpatched kernel. Confirm enforcement before assuming you are protected:

# RHEL / AlmaLinux / Rocky -- verify SELinux is enforcing
getenforce
# If output is Permissive or Disabled, enforce it now:
setenforce 1
sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config
docker info 2>/dev/null | grep -i selinux

# Ubuntu / Debian -- verify AppArmor docker profile is loaded
aa-status 2>/dev/null | grep docker
# If missing, load it:
apparmor_parser -r /etc/apparmor.d/docker 2>/dev/null

Option 3: Drop CAP_SYS_ADMIN from Containers

Because writing to release_agent requires CAP_SYS_ADMIN in the user namespace, dropping that capability breaks the exploit chain at the container level:

# Docker -- drop all caps, add back only what you need
docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE your-image

# Docker Compose -- add under each service definition:
# security_opt:
#   - no-new-privileges:true
# cap_drop:
#   - ALL

# Kubernetes -- enforce via SecurityContext:
# securityContext:
#   allowPrivilegeEscalation: false
#   capabilities:
#     drop: ["ALL"]
#   runAsNonRoot: true

The Permanent Fix: Migrate to cgroups v2

Patching the kernel closes CVE-2022-0492 at the code level. However, staying on cgroups v1 still leaves you exposed to any future v1-specific vulnerabilities — it is an aging subsystem no longer under active development. Because of that, migrating to cgroups v2 is the correct long-term fix. Every modern Linux distribution now defaults to cgroups v2, which has a fundamentally stronger security model.

Enable cgroups v2 on RHEL / AlmaLinux / Rocky 9

# RHEL 9 / AlmaLinux 9 / Rocky 9 default to cgroups v2 -- verify:
stat -fc %T /sys/fs/cgroup/   # Should return cgroup2fs

# If grub arguments are forcing v1, remove them:
grep cgroup /proc/cmdline
grubby --update-kernel=ALL --remove-args='systemd.unified_cgroup_hierarchy=0'
reboot
stat -fc %T /sys/fs/cgroup/   # Confirm cgroup2fs after reboot

Enable cgroups v2 on Ubuntu / Debian

# First, check the current state:
stat -fc %T /sys/fs/cgroup/

# If still on v1, add the kernel parameter to grub:
grep GRUB_CMDLINE_LINUX /etc/default/grub
sed -i 's/GRUB_CMDLINE_LINUX="\(.*\)"/GRUB_CMDLINE_LINUX="\1 systemd.unified_cgroup_hierarchy=1"/' \
  /etc/default/grub
update-grub && reboot
stat -fc %T /sys/fs/cgroup/   # Confirm cgroup2fs

Configure Docker for cgroups v2

# After enabling cgroups v2 on the host, update Docker:
cat > /etc/docker/daemon.json << 'DEOF'
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {"max-size": "100m"},
  "storage-driver": "overlay2"
}
DEOF
systemctl restart docker
docker info | grep -i cgroup
# Expected: Cgroup Version: 2  and  Cgroup Driver: systemd

Migrate Kubernetes Nodes to cgroups v2

# Step 1: Drain the target node
kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data

# Step 2: Enable cgroups v2 on the node OS (see RHEL or Ubuntu steps above)

# Step 3: Update kubelet to use systemd cgroup driver
cat > /var/lib/kubelet/config.yaml << 'KEOF'
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
KEOF
systemctl restart kubelet

# Step 4: Uncordon and verify
kubectl uncordon NODE_NAME
kubectl get node NODE_NAME -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'

Detect Exploitation Attempts

Even after patching, setting up ongoing monitoring is worth the five minutes it takes. An active CVE-2022-0492 attack writes to release_agent files on the host, so auditd catches it directly:

# Enable auditd rule to monitor cgroup release_agent writes
auditctl -w /sys/fs/cgroup -p wa -k cgroup_release_agent 2>/dev/null || \
  echo 'Install and enable auditd first'

# Review the audit log for any release_agent activity
ausearch -k cgroup_release_agent 2>/dev/null | tail -50

# Check for unexpected setuid binaries created recently
find / -perm -4000 -newer /var/log/lastlog -ls 2>/dev/null | grep -v proc

# Watch release_agent content in real time
watch -n30 'find /sys/fs/cgroup -name release_agent -exec cat {} \; 2>/dev/null'

Beyond auditd, also verify that no containers are running with --privileged mode in production. Privileged containers bypass most of these mitigations entirely, so they deserve their own audit. Our Linux server hardening checklist covers the full auditd baseline plus container security configuration for production systems.

Quick Reference: Everything You Need to Do

Docker vs Podman: What This Changes

CVE-2022-0492 adds another data point to the Docker vs Podman security comparison. Because Podman's rootless architecture runs containers entirely within user namespaces without a central root-privileged daemon, the impact of cgroups v1 privilege issues is significantly reduced. When you also run rootless Podman on cgroups v2, the entire release_agent attack surface simply does not exist. For new container deployments in 2026, that combination is the safer starting point. Our Docker vs Podman on Linux guide covers the full security comparison in detail.

What the CISA KEV Listing Actually Means

CISA only adds entries to the KEV catalog when there is credible evidence of active exploitation in the wild — not just proof-of-concept research. So the June 2, 2026 addition confirms that organized threat actors are actively targeting real systems with this flaw today. As SecurityWeek explains, the four-year gap between the original patch and the KEV listing follows a well-established pattern: attackers wait until a significant population of unpatched legacy systems accumulates, then systematically work through them. Every container host still running cgroups v1 on an unpatched kernel is a live target in that sweep.

Conclusion

The CVE-2022-0492 container escape was patched in 2022, yet CISA confirmed active exploitation on June 2, 2026. So the first step is to check your cgroups version on every container host. After that, verify your kernel version against the patch threshold for your distro. For Kubernetes environments specifically, check every worker node kernel individually — the control plane version tells you nothing about the nodes. Once you have confirmed exposure, enable SELinux or AppArmor enforcement if it is currently off, then migrate to cgroups v2 for the permanent fix. Finally, drop CAP_SYS_ADMIN from any container that does not explicitly need it, and enable auditd monitoring on release_agent writes so you know immediately if someone is probing your infrastructure. This flaw has been patchable for years. There is no good reason for it to remain in production systems in 2026.