Linux cgroups v1 release_agent container escape (CVE-2022-0492) re-enters active exploitation

Background. CVE-2022-0492 was disclosed and patched in early 2022; Palo Alto Unit 42 published the canonical technical analysis in March 2022, walking through how the cgroup-v1 release_agent mechanism becomes a container-escape primitive and how earlier mainline kernels shipped without the missing capability check (Unit 42, 2022-03-07). It has sat quietly for four years. CISA's addition of the CVE to the Known Exploited Vulnerabilities catalog on 2026-06-02 (CISA, 2026-06-02) signals fresh in-the-wild exploitation — consistent with attackers harvesting the large tail of unpatched legacy kernels still running container-dense workloads.

The bug. The kernel's cgroup_release_agent_write() handler in kernel/cgroup/cgroup-v1.c failed to verify that a process writing the cgroup-v1 release_agent file holds CAP_SYS_ADMIN in the initial user namespace — CWE-862 Missing Authorization, CVSS 7.0 (Red Hat, CVE-2022-0492). The release_agent is a host path the kernel executes as root on the host whenever the last task leaves a cgroup that has notify_on_release set. Because the write was under-authorised, a process that can mount or reach a writable cgroup-v1 hierarchy can point release_agent at an attacker-controlled script and then empty a cgroup to trigger it — code execution crosses the container boundary into the host root context. This is the textbook T1611 Escape to Host (MITRE ATT&CK T1611).

Exploitation prerequisites — where it actually bites. The attacker needs prior code execution inside a container (initial access via some other vector — an exposed app, a malicious image, a prior § 1-class foothold). The escape requires the ability to mount a cgroup-v1 hierarchy and write release_agent, which in turn requires CAP_SYS_ADMIN in the user namespace that owns that hierarchy. Unit 42 details the dangerous unprivileged path: a process creates a new user namespace (unshare) to obtain CAP_SYS_ADMIN within that namespace and mount a cgroup-v1 hierarchy — viable when the container runtime has not confined the workload with a seccomp profile blocking the mount/unshare calls or an AppArmor/SELinux policy (Unit 42's final write-up scopes the technique to this unprivileged path). A workload directly granted CAP_SYS_ADMIN reaches the same mount/release_agent primitive trivially, which is why over-broad capability grants are dangerous in their own right. The common denominator is a permissively-profiled container: no seccomp, no mandatory-access-control LSM. Self-hosted Kubernetes clusters and bespoke runtimes that strip the default Docker seccomp profile are the typical exposed surface; managed clusters with hardened pod-security defaults and cgroup-v2-only hosts are largely out of scope.

Kill chain. Initial access into the container (T1190/T1610-class) → discovery of cgroup-v1 writability and capability set (T1082) → T1611 Escape to Host: mount a cgroup-v1 controller, set notify_on_release=1, write a host-path payload into release_agent, then spawn-and-exit a process inside a child cgroup so the kernel executes the payload as host root → host-level execution, after which the operator has the usual post-escape options (credential theft from the host, lateral movement to the orchestrator control plane, T1610 deploying further containers).

Hunt and detection concepts (no rule code): the highest-signal artefact is a write to a release_agent file anywhere under /sys/fs/cgroup/** by a non-root or containerised process — Falco/sysdig ship a community rule for exactly this, and auditd can watch the path. Pair it with auditing of in-container mount() of cgroup filesystems and unshare/clone calls that create new user namespaces (auditd syscall rules), and with Linux Sysmon (EID 1) on processes whose executable path was just written via a cgroup release_agent. On the host, a root-context process spawned with no normal parent lineage (kernel-invoked) executing a script from a container-writable path is the escape firing.

Hardening / mitigation. Patch the kernel to 5.17+ or apply the distro backport (every maintained enterprise distro shipped one in 2022) — this restores the CAP_SYS_ADMIN check and closes the class. Independently of patching, the misconfiguration controls neutralise the path: enforce a seccomp profile (the Docker/containerd defaults already block the required mount), apply AppArmor or SELinux confinement to every workload, never grant CAP_SYS_ADMIN to application containers, and move hosts to cgroup v2 exclusively (systemd.unified_cgroup_hierarchy=1), which does not expose the release_agent escape primitive at all. Mounting /sys/fs/cgroup read-only inside containers removes the write target. For Swiss/EU public-sector teams running self-managed Kubernetes or container hosts on long-lived LTS kernels, this KEV addition is the prompt to verify both the kernel patch level and the pod-security/seccomp baseline, since either control alone defeats the escape.