Threat reportVulnerabilityTL-2026-0662
Linux Kernel cgroups v1 release_agent Container Escape & Privilege Escalation (CVE-2022-0492) — Added to CISA KEV (Active Exploitation)
Linux Kernel cgroups v1 release_agent Container Escape & (TL-2026-0662), also tracked as cgroups release_agent container escape, is a critical-severity software vulnerability scored CVSS 7.8, first published 2026-06-02. It has no confirmed attribution, affects Linux Linux Kernel, references 1 CVE (CVE-2022-0492), maps to 13 MITRE ATT&CK techniques (T1021, T1059.004, T1068), and is covered by 9 detection rules and 13 indicators of compromise.
- CVSS
- 7.8/10Critical
- CVEs
- 1Referenced vulnerabilities
- Techniques
- 13MITRE ATT&CK
- Actors
- 0Not attributed
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 13Indicators of compromise
Key facts for TL-2026-0662
- Threat ID
- TL-2026-0662
- Also known as
- cgroups release_agent container escape, release_agent privilege escalation
- Severity
- CRITICAL
- CVSS
- 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
- Status
- ACTIVE
- Category
- VULNERABILITY
- First published
- Last reviewed
- Attribution confidence
- NONE
- Motivation
- UNKNOWN
- Target sectors
- technology, cloud-service-providers, financial, government, healthcare, telecommunications
- Target regions
- Global
- Detection rules
- 9
- Indicators of compromise
- 13
How Linux Kernel cgroups v1 release_agent Container Escape & works
CVE-2022-0492 is an improper-authorization flaw in the Linux kernel's cgroup_release_agent_write function (kernel/cgroup/cgroup-v1.c) that lets an attacker abuse the cgroups v1 release_agent feature to execute arbitrary code as root in the initial namespace, enabling container escape and local privilege escalation. CISA added it to the Known Exploited Vulnerabilities Catalog on 2026-06-02 citing evidence of active exploitation; FCEB agencies must remediate under BOD 22-01.
CVE-2022-0492 is a privilege-escalation and container-escape vulnerability in the Linux kernel's cgroups (control groups) version 1 subsystem. The flaw resides in cgroup_release_agent_write() in kernel/cgroup/cgroup-v1.c, which handles writes to the per-cgroup 'release_agent' file. The release_agent feature instructs the kernel to execute a specified binary — as full root in the initial (host) namespace — whenever the last task leaves a cgroup that has notify_on_release=1. Before the fix, the write handler failed to verify that the writing process held the appropriate capability (CAP_SYS_ADMIN) over the initial user namespace that owns the cgroup filesystem. The kernel only confirmed the caller was 'capable' in some namespace, not that it was authorized over the resource being modified. This is classed as CWE-287 (Improper Authentication) and CWE-862 (Missing Authorization).
Because an unprivileged user on most modern Linux distributions can create a new user namespace via unshare(CLONE_NEWUSER) and obtain CAP_SYS_ADMIN inside it, then mount a cgroup v1 hierarchy (e.g. the RDMA controller) within a new mount+cgroup namespace, the attacker can write an arbitrary path into release_agent and force the kernel to run it as root on the host. There are two principal exploitation scenarios. (1) Bare-host local privilege escalation: an unprivileged user escalates to root by chaining unshare -UrmC, mounting cgroupfs, writing a payload path to release_agent, setting notify_on_release, and triggering cgroup release. (2) Container escape: a container process that holds CAP_SYS_ADMIN (or can acquire it via user-namespace creation) and is not confined by an enforcing AppArmor or SELinux policy can break out to the host by the same release_agent mechanism, resolving the host-side path of its overlay/upperdir from /etc/mtab or /proc/self/cgroup so the dropped script is reachable from the root mount namespace.
The exploitation primitive is the long-known 'privileged container' release_agent escape, but CVE-2022-0492 broadened the exposure: the missing authorization check meant the technique was reachable in configurations previously believed safe, and reliably from an unprivileged user-namespace context. Public proof-of-concept code is widely available and the technique is trivially weaponized (a few shell commands), which is consistent with CISA's active-exploitation determination. Post-escape, an attacker operating as host root can read host secrets and mounted volumes, establish persistence, deploy additional containers, and move laterally across the cluster or host fleet.
Critical mitigating factors: an enforcing AppArmor profile (e.g. Docker's default docker-default profile, which denies writes to release_agent) or SELinux in enforcing mode blocks the write or the subsequent execution; dropping CAP_SYS_ADMIN from containers removes the primary path; and seccomp policies that block the unshare/mount syscalls neutralize the unprivileged-user variant. The upstream fix (commit 24f6008564183aa120d07c03d9289519c2fe02af, 'cgroup-v1: Require capabilities to set release_agent') adds an ns_capable() check requiring CAP_SYS_ADMIN over the user namespace that owns the cgroup filesystem, plus a check that the opener of the file is privileged. The flaw was reported by Yiqi Sun and Kevin Wang and analyzed in depth by Palo Alto Networks Unit 42. Fixed in Linux 5.17 and backported to stable trees (5.16.5, 5.15.19, 5.10.96, 5.4.176, 4.19.228, 4.14.265, 4.9.300) and to enterprise kernels by Red Hat, SUSE, Ubuntu, and Debian.
MITRE ATT&CK techniques used in TL-2026-0662
Lateral Movement
Execution
T1059.004 Command and Scripting Interpreter: Unix Shell; T1609 Container Administration Command
Privilege Escalation
T1068 Exploitation for Privilege Escalation; T1548 Abuse Elevation Control Mechanism; T1611 Escape to Host
Discovery
T1082 System Information Discovery; T1613 Container and Resource Discovery
Initial Access
T1190 Exploit Public-Facing Application
Defense Evasion
T1211 Exploitation for Stealth
defense-impairment
T1222 File and Directory Permissions Modification
Persistence
T1543 Create or Modify System Process
Credential Access
Affected products and versions in Linux Kernel cgroups v1 release_agent Container Escape &
- Linux — Linux Kernel
Vulnerable versions: < 5.17 (cgroups v1 with release_agent)
Fixed in: 5.17; 5.16.5; 5.15.19; 5.10.96; 5.4.176; 4.19.228; 4.14.265; 4.9.300 - Red Hat — Red Hat Enterprise Linux
Vulnerable versions: RHEL 7; RHEL 8; RHEL 9
Fixed in: See RHSA kernel errata - Canonical — Ubuntu
Vulnerable versions: 18.04 LTS; 20.04 LTS; 21.10
Fixed in: Patched via USN kernel updates - Debian — Debian GNU/Linux
Vulnerable versions: 10 (buster); 11 (bullseye)
Fixed in: DSA-5095; DSA-5096
Remediation for Linux Kernel cgroups v1 release_agent Container Escape &
Patches
- Linux kernel 5.17 (mainline fix)
- Stable backports: 5.16.5, 5.15.19, 5.10.96, 5.4.176, 4.19.228, 4.14.265, 4.9.300
- Red Hat RHSA kernel updates (RHEL 7/8/9); Ubuntu USN; Debian DSA-5095 / DSA-5096; SUSE SUSE-SU updates
Immediate actions
- Apply the kernel update containing commit 24f6008564183aa120d07c03d9289519c2fe02af (Linux 5.17 or backported stable/enterprise kernels) — FCEB agencies must remediate per CISA BOD 22-01.
- Drop CAP_SYS_ADMIN from all containers that do not strictly require it (docker run --cap-drop=ALL or remove from securityContext.capabilities).
- Ensure AppArmor (docker-default) or SELinux is enabled and enforcing on all container hosts — both block the release_agent write/exec path.
Workarounds
- Run containers unprivileged and without CAP_SYS_ADMIN.
- Keep AppArmor/SELinux in enforcing mode (do not run containers with --security-opt apparmor=unconfined or --privileged).
- Set kernel.unprivileged_userns_clone=0 to block the unprivileged-user variant.
Longer-term hardening
- Migrate hosts to cgroups v2 (unified hierarchy), which removes the release_agent mechanism entirely.
- Enforce a restrictive seccomp profile that blocks unshare/mount/clone with namespace flags for workloads that do not need them.
- Disable unprivileged user namespaces where not required: sysctl kernel.unprivileged_userns_clone=0 (Debian/Ubuntu) or user.max_user_namespaces=0.
- Adopt admission-control policy (e.g. Kubernetes Pod Security Standards 'restricted', OPA/Gatekeeper, Kyverno) to forbid privileged pods and CAP_SYS_ADMIN.
CVEs associated with Linux Kernel cgroups v1 release_agent Container Escape &
Weaknesses (CWE) in Linux Kernel cgroups v1 release_agent Container Escape &
Timeline of Linux Kernel cgroups v1 release_agent Container Escape &
- Upstream fix authored: commit 24f6008564183aa120d07c03d9289519c2fe02af 'cgroup-v1: Require capabilities to set release_agent', adding an ns_capable(CAP_SYS_ADMIN) check over the owning user namespace.
- Vulnerability reported by Yiqi Sun and Kevin Wang; Red Hat Bugzilla #2051505 created for triage and backporting.
- Coordinated public disclosure. NVD publishes CVE-2022-0492 (CVSS 7.8). Palo Alto Networks Unit 42 publishes detailed technical analysis and container-escape conditions.
- Distribution advisories released — Debian DSA-5095 / DSA-5096, Ubuntu USN kernel updates, Red Hat RHSA errata, and SUSE updates ship backported fixes.
- Public Docker cgroups container-escape PoC referenced on Packet Storm, lowering the bar for weaponization.
- FCEB remediation mandated under Binding Operational Directive 22-01 following the KEV addition.
- CISA adds CVE-2022-0492 to the Known Exploited Vulnerabilities Catalog based on evidence of active exploitation.
Sources cited for Linux Kernel cgroups v1 release_agent Container Escape &
- CISA Adds Two Known Exploited Vulnerabilities to Catalog
- CISA Known Exploited Vulnerabilities Catalog
- NVD - CVE-2022-0492
- Unit 42: New Linux Vulnerability CVE-2022-0492 Affecting cgroups - Can Containers Escape?
- Red Hat Bugzilla #2051505 - CVE-2022-0492
- Upstream patch: cgroup-v1: Require capabilities to set release_agent
- Debian Security Advisory DSA-5095-1 linux
- Docker cgroups Container Escape (Packet Storm)
Detection coverage for TL-2026-0662
As of 2026-06-02, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-0662 across Splunk SPL, Microsoft KQL and Sigma, covering 13 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.