--- schema: 1 kind: vulnerability title: Linux cgroups v1 release_agent container escape (CVE-2022-0492) re-enters active exploitation headline: Linux cgroups v1 release_agent container escape (CVE-2022-0492) re-enters active exploitation summary: "A four-year-old Linux container-escape, CVE-2022-0492, re-enters CISA KEV — the cgroup-v1 release_agent missing-CAP_SYS_ADMIN check lets a process in a permissively-profiled container execute code at host level. Today's deep dive (§ 5) covers the escape path and the mandatory-access-control hardening that closes it (CISA, 2026-06-02)." discovered_at: "2026-06-03T05:00:09Z" event_date: 2026-06-02 run_id: 2026-06-03-ee0eae61 priority: high immediate_action: null tags: - vulnerabilities - actively-exploited - priv-esc - lpe - cloud - cisa-kev - patch-available regions: - global sectors: - public-sector - technology entities: [] cves: - id: CVE-2022-0492 cvss: "7.0" epss: null type: priv-esc vector: local auth: post-auth status: - exploited - cisa-kev - patch-available sources: - url: "https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/" publisher: Unit 42 role: primary - url: "https://access.redhat.com/security/cve/cve-2022-0492" publisher: Red Hat CVE-2022-0492 role: corroborating - url: "https://www.cisa.gov/news-events/alerts/2026/06/02/cisa-adds-two-known-exploited-vulnerabilities-catalog" publisher: CISA role: corroborating closed_sources: [] evidence: - quote: Background. publisher: ctipilot v2 brief (migrated) verification: multi-source sourcing_note: "migration: evidence backfilled from v2 brief body (item predates the Evidence footer field)" confidence: high update_of: null references: [] deep_dive: true deep_dive_category: linux-lpe org_triage: null watchlist_hit: false actions: - "**Verify container hosts on two axes for CVE-2022-0492** (§ 5): kernel ≥ 5.17 (or distro backport) **and** a seccomp/AppArmor/SELinux baseline on every workload; migrate hosts to cgroup-v2-only. Deploy the Falco/`auditd` watch on `release_agent` writes under `/sys/fs/cgroup`." migrated_from: briefs/2026-06-03.md --- **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](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/)). 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](https://www.cisa.gov/news-events/alerts/2026/06/02/cisa-adds-two-known-exploited-vulnerabilities-catalog)) 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](https://access.redhat.com/security/cve/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](https://attack.mitre.org/techniques/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.