This is a fire escape that only matters after the attacker is already inside the building
CVE-2022-0492 is a Linux kernel cgroups v1 release_agent authorization bug. If an attacker can run code locally and reach the right cgroup controls, they can point release_agent at a program of their choice and get it executed by the host kernel as root, which turns a container foothold into a host escape. Upstream affected ranges called out by NVD are broad: Linux kernels from 2.6.24 up to fixed releases 4.9.301, 4.14.266, 4.19.229, 5.4.177, 5.10.97, 5.15.20, 5.16.6, and 5.17-rc3.
The vendor's HIGH 7.8 score is technically defensible for raw impact, but it overstates real fleet risk in hardened enterprise estates. This is not unauthenticated remote code execution; it is a post-initial-access privilege-escalation/container-escape chain that usually needs root inside a container plus weak runtime settings such as cgroups v1, disabled or ineffective seccomp/AppArmor/SELinux, or a privileged/unconfined pod. In other words: severe impact, narrow path.
4 steps from start to impact.
Get code execution in a container or local shell
- Local code execution on the target Linux system or inside a container
- A vulnerable host kernel
- This prerequisite already implies the attacker has passed your external perimeter and landed code execution
- If the vulnerable kernel is only present on a subset of worker nodes, the reachable population drops fast
Create namespaces with unshare and mount cgroup v1
unshare -UrmC to create user, mount, and cgroup namespaces, then mounts a v1 cgroup controller with mount -t cgroup. Public walkthroughs from Sysdig show this exact sequence. The goal is to reach a writable release_agent file from inside the attacker's execution context.- cgroups v1 available on the host
- The runtime allows
unshare/new namespaces or otherwise permits equivalent setup - The container is running as root or has sufficient capability to manipulate the target files
- Default seccomp profiles often block
unshare - Many modern estates are moving to cgroups v2, which removes this exact path
- Rootless or non-root containers usually break the straightforward exploit chain
unshare, cgroup mounts, and writes involving release_agent. Scanner coverage is generally weak because exploitability depends on runtime policy, not just package version.Bypass runtime hardening and write release_agent
release_agent file and enables notify_on_release for a child cgroup. The upstream fix added a missing requirement for CAP_SYS_ADMIN in the initial user namespace when setting release_agent, closing the authorization gap. Before that fix, the kernel could be tricked into launching the chosen helper with full host privileges.- Ability to mount and interact with the relevant cgroup v1 hierarchy
- AppArmor/SELinux not blocking the mount/write path, or the workload is privileged/unconfined
- A container runtime configuration that exposes enough host semantics for the host path trick
- SELinux on OpenShift blocks the escape path by default according to Red Hat's bug record
- AppArmor and SELinux commonly stop the mount/write sequence even when the kernel itself is vulnerable
- Privileged containers are already one bad decision away from breakout; this CVE is just one of several escape options there
/sys/fs/cgroup/**/release_agent, notify_on_release, unexpected cgroup mounts, and short-lived shells spawned around those writes.Trigger host-side execution as root
- Successfully written
release_agentandnotify_on_release - Ability to trigger cgroup release
- If earlier hardening steps block the path, this trigger never matters
- The impact is node-local unless the attacker can laterally move using orchestration credentials, secrets, or mounted cloud metadata
The supporting signals.
| In-the-wild status | Treat as known exploited because the prompt's upstream intel says KEV listed: YES. Public campaign detail is thin, so confidence on *who* is exploiting it is lower than confidence that exploitation has occurred. |
|---|---|
| Proof-of-concept availability | Public exploitation guidance is readily available: Sysdig published a step-by-step container escape walkthrough, and NVD references a Packet Storm write-up titled Docker cgroups Container Escape. |
| EPSS | 0.05238 from the prompt. That is useful threat signal, but once KEV/active exploitation enters the picture, EPSS stops being the deciding factor. |
| KEV status and dates | KEV: Yes per prompt intel. Direct public-date confirmation was inconsistent in this browsing session, so rely on the upstream intel for status and do not overfit to the crawled dates. |
| CVSS vector | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — that is a classic local privesc vector: easy once local execution exists, but it says nothing about how hard getting that initial foothold is. |
| Affected versions | NVD tracks vulnerable upstream Linux kernels from 2.6.24 through the unfixed branches, including versions before 4.9.301, 4.14.266, 4.19.229, 5.4.177, 5.10.97, 5.15.20, 5.16.6, and 5.17-rc3. |
| Fixed versions | Upstream fix is commit 24f6008564183aa120d07c03d9289519c2fe02af, first noted in 5.17-rc3. Distro backports include Ubuntu 20.04: 5.4.0-105.119, 18.04: 4.15.0-173.182, 16.04: 4.4.0-222.255; Debian bullseye 5.10.103-1; Debian buster 4.19.232-1. |
| Scanning / exposure reality | There is no meaningful Shodan/Censys/GreyNoise internet-exposure view for this CVE because it is not directly network-reachable. The real exposure question is internal: *which nodes run vulnerable kernels and host privileged, root, or unconfined containers on cgroups v1?* |
| Disclosure | Public disclosure landed on 2022-03-03 in NVD; the oss-security post discussing the fix is dated 2022-02-04. |
| Researchers / reporting | The oss-security notice credits Yiqi Sun and Kevin Wang of Huawei Security Team for the work leading to the fix. |
noisgate verdict.
The decisive factor is that exploitation usually requires post-compromise local execution plus a weak container runtime posture; that sharply narrows real-world reach compared with the vendor's raw-impact score. The KEV signal prevents this from dropping into backlog-only territory, but the attack path is still far from universal across hardened Linux fleets.
Why this verdict
- Requires local or in-container execution first — this is not an external entry bug; it presumes the attacker is already on the box or in a workload.
- Usually needs root and unsafe runtime settings — practical exploitation commonly depends on root inside the container, cgroups v1, and weakened seccomp/AppArmor/SELinux or a privileged/unconfined pod.
- Modern controls cut the reachable population — default seccomp, SELinux on OpenShift, AppArmor, and cgroups v2 all add real friction that breaks many public exploit chains.
- KEV keeps it relevant — known exploitation evidence means defenders should not ignore it just because the path is narrow.
Why not higher?
If this were unauthenticated remote code execution on a ubiquitous edge service, it would be a very different conversation. But CVE-2022-0492 sits behind multiple compounding prerequisites: prior compromise, local execution, container/root context, and runtime misconfiguration. Those are exactly the kind of real-world brakes that should push severity down.
Why not lower?
The impact is still full host-root compromise when the path exists, and public exploitation guidance is mature. Also, KEV status means somebody has already found enough of these weak configurations in the wild to matter, so writing it off as harmless local noise would be too optimistic.
What to do — in priority order.
- Ban privileged and unconfined containers — Enforce admission controls so pods cannot run
privileged,unconfined, or with dangerous capability sets unless explicitly approved. Because the prompt indicates KEV-listed exploitation, deploy this immediately, within hours on exposed clusters; it directly removes the easiest escape path. - Enforce seccomp and LSM profiles — Require a non-
unconfinedseccomp profile and keep AppArmor or SELinux enforcing on worker nodes. Do this immediately, within hours where possible, because public exploit chains rely on namespace creation, cgroup mounts, or writes that these controls often block. - Reduce or eliminate cgroups v1 usage — Move workloads and hosts to cgroups v2 where your platform supports it, or at minimum identify nodes still exposing vulnerable v1 controller behavior. This is a strong structural mitigation; start immediately, within hours for exposed clusters and complete as part of the permanent fix.
- Disable unprivileged user namespaces where operationally safe — If your platform does not require them, disabling unprivileged user namespaces can break common exploitation setups using
unshare. Apply this immediately, within hours after compatibility testing, especially on multi-tenant container hosts.
- A WAF does nothing here; the exploit path is local kernel/runtime abuse after code execution already exists.
- Internet perimeter scanning is the wrong control; this flaw is not directly fingerprintable from Shodan-style exposure data.
- Patching container images only is insufficient because the vulnerable component is the host kernel, not the application image.
Crowdsourced verification payload.
Run this on the target Linux host, not from an auditor workstation. Invoke it as sudo bash ./check-cve-2022-0492.sh; root is recommended so the script can inspect mounts and distro metadata. The script is conservative: it returns PATCHED where it can positively confirm known Ubuntu fixes or clearly fixed upstream versions, VULNERABLE where it can positively place the host in a vulnerable range, and UNKNOWN when distro backports make a safe call impossible.
#!/usr/bin/env bash
# check-cve-2022-0492.sh
# Purpose: conservative host-side check for CVE-2022-0492
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
status="UNKNOWN"
reason="Insufficient evidence to determine patch state safely"
krel="$(uname -r 2>/dev/null || true)"
kbase="${krel%%-*}"
os_id="unknown"
os_ver="unknown"
if [ -r /etc/os-release ]; then
# shellcheck disable=SC1091
. /etc/os-release
os_id="${ID:-unknown}"
os_ver="${VERSION_ID:-unknown}"
fi
have_cgv1="no"
if grep -Eq ' - cgroup ' /proc/self/mountinfo 2>/dev/null; then
have_cgv1="yes"
fi
verlt() {
[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]
}
verge() {
[ "$1" = "$2" ] || ! verlt "$1" "$2"
}
set_result() {
status="$1"
reason="$2"
}
check_ubuntu() {
case "$os_ver" in
22.04|24.04|24.10|25.04|25.10)
set_result "PATCHED" "Ubuntu release marked not affected by Canonical"
return
;;
21.10)
if verlt "$kbase" "5.13.0"; then
set_result "UNKNOWN" "Unexpected Ubuntu 21.10 kernel string: $krel"
elif verlt "$krel" "5.13.0-37.42"; then
set_result "VULNERABLE" "Ubuntu 21.10 kernel predates Canonical fixed build 5.13.0-37.42"
else
set_result "PATCHED" "Ubuntu 21.10 kernel is at or above Canonical fixed build 5.13.0-37.42"
fi
return
;;
20.04)
if verlt "$krel" "5.4.0-105.119"; then
set_result "VULNERABLE" "Ubuntu 20.04 kernel predates Canonical fixed build 5.4.0-105.119"
else
set_result "PATCHED" "Ubuntu 20.04 kernel is at or above Canonical fixed build 5.4.0-105.119"
fi
return
;;
18.04)
if verlt "$krel" "4.15.0-173.182"; then
set_result "VULNERABLE" "Ubuntu 18.04 kernel predates Canonical fixed build 4.15.0-173.182"
else
set_result "PATCHED" "Ubuntu 18.04 kernel is at or above Canonical fixed build 4.15.0-173.182"
fi
return
;;
16.04)
if verlt "$krel" "4.4.0-222.255"; then
set_result "VULNERABLE" "Ubuntu 16.04 kernel predates Canonical fixed build 4.4.0-222.255"
else
set_result "PATCHED" "Ubuntu 16.04 kernel is at or above Canonical fixed build 4.4.0-222.255"
fi
return
;;
esac
}
check_generic_upstream() {
# If the kernel release string has distro packaging suffixes, upstream-only checks are unreliable.
if [ "$krel" != "$kbase" ] && printf '%s' "$krel" | grep -Eq '(generic|amd64|el[0-9]|uek|aws|azure|gcp|oracle|fc[0-9]|amzn)'; then
set_result "UNKNOWN" "Distro/backport kernel detected ($krel); exact vendor advisory needed"
return
fi
if verlt "$kbase" "4.9.301"; then
if verge "$kbase" "2.6.24"; then
set_result "VULNERABLE" "Kernel falls in an upstream vulnerable range before 4.9.301"
return
fi
fi
if verge "$kbase" "4.10" && verlt "$kbase" "4.14.266"; then
set_result "VULNERABLE" "Kernel falls in upstream vulnerable range 4.10 to <4.14.266"
return
fi
if verge "$kbase" "4.15" && verlt "$kbase" "4.19.229"; then
set_result "VULNERABLE" "Kernel falls in upstream vulnerable range 4.15 to <4.19.229"
return
fi
if verge "$kbase" "4.20" && verlt "$kbase" "5.4.177"; then
set_result "VULNERABLE" "Kernel falls in upstream vulnerable range 4.20 to <5.4.177"
return
fi
if verge "$kbase" "5.5" && verlt "$kbase" "5.10.97"; then
set_result "VULNERABLE" "Kernel falls in upstream vulnerable range 5.5 to <5.10.97"
return
fi
if verge "$kbase" "5.11" && verlt "$kbase" "5.15.20"; then
set_result "VULNERABLE" "Kernel falls in upstream vulnerable range 5.11 to <5.15.20"
return
fi
if verge "$kbase" "5.16" && verlt "$kbase" "5.16.6"; then
set_result "VULNERABLE" "Kernel falls in upstream vulnerable range 5.16 to <5.16.6"
return
fi
if verge "$kbase" "5.17"; then
set_result "PATCHED" "Kernel is newer than the affected upstream branches"
return
fi
set_result "UNKNOWN" "Kernel version not safely classifiable with generic upstream logic"
}
if [ -z "$krel" ]; then
echo "UNKNOWN - unable to read kernel release"
exit 2
fi
if [ "$os_id" = "ubuntu" ]; then
check_ubuntu
else
check_generic_upstream
fi
# Add context about cgroup v1 exposure without changing patch verdict.
context="kernel=$krel os=$os_id/$os_ver cgroup_v1=$have_cgv1"
echo "$status - $reason ($context)"
case "$status" in
PATCHED) exit 0 ;;
VULNERABLE) exit 1 ;;
*) exit 2 ;;
esac
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.