CVE-2022-0492 was fixed four years ago. CISA just added it to the Known Exploited Vulnerabilities catalog with a June 5 deadline — because the container hosts it breaks are exactly the ones nobody patched. Why a closed bug is suddenly a live threat, and what to verify before the boundary you trust turns out not to be one.
There is a particular category of vulnerability that does not generate headlines when it is disclosed and does not generate panic when it is patched, yet remains a live problem for years because the affected systems are exactly the ones nobody is watching. CVE-2022-0492 is that kind of flaw. It was disclosed in February 2022 by Huawei researchers Yiqi Sun and Kevin Wang, fixed in the mainline kernel within weeks, and backported into every major distribution shortly after. By most measures it was a closed case before most teams had finished reading the advisory.
Its addition to the KEV catalog more than four years later is not a story about a new exploit. It is a story about where the patch never landed — the container hosts whose kernels were forgotten while everyone diligently patched the containers running on top of them, the embedded and appliance-class devices shipped with a vendor-locked kernel, the air-gapped boxes that never see an update. KEV status is CISA’s way of saying that those systems are being hit right now. The score on the page is High (CVSS 7.8); the more useful signal is the verb: exploited, not theoretical.
| Field | Detail |
|---|---|
| CVE | CVE-2022-0492 |
| Vulnerability Class | Improper authentication → privilege escalation / container escape |
| Affected Component | cgroups v1 release_agent — cgroup_release_agent_write() in kernel/cgroup/cgroup-v1.c |
| Severity | High — CVSS 7.8 (local attack vector) |
| Disclosed | February 2022 — Yiqi Sun & Kevin Wang (Huawei) |
| Patched | Kernel 5.17-rc3; distro backports March 2022 |
| CISA KEV Status | Added June 2, 2026 — confirmed active exploitation |
| FCEB Deadline | June 5, 2026 |
| Not Affected | cgroups v2 — no release_agent mechanism |
| Defender Priority | PATCH & REBOOT host kernels · verify cgroups v2 · confirm seccomp + MAC enforcement |
The operating assumption behind most container deployments is that the container is an isolation boundary — that a process inside it is meaningfully separated from the host and from its neighbours. That assumption is doing a lot of work, and it is only as true as the layered defences holding it up. A container is not a virtual machine. It is a process on the host kernel, fenced in by a stack of distinct Linux mechanisms: namespaces, capabilities, seccomp filters, and a mandatory access control layer such as AppArmor or SELinux. Each one removes a class of escape. None of them is the boundary on its own.
CVE-2022-0492 matters because it targets the seam between two of those assumptions — that running as root inside a container is contained, and that the kernel validates who is allowed to perform privileged cgroup operations. When a flaw lets a containerised process reach through that seam, the impact is not a degraded container. It is root on the host, and from there, every other container sharing that host. For anyone running multi-tenant workloads, shared CI runners, or Kubernetes nodes packing many pods onto one machine, that is the difference between a contained incident and a node-wide compromise.
This is not a universal escape. The same layered model that defines container security is what neutralises this flaw in well-configured environments — the default Docker seccomp profile and the default AppArmor/SELinux policies each block it independently. The exposure is concentrated in the exceptions: containers run with confinement stripped, and host kernels that were never updated. Signal, not severity, is what matters here.
Control groups (cgroups) are the kernel feature that limits and accounts for the resources a group of processes can use. The v1 implementation includes a convenience feature called release_agent: a path to a program the kernel runs automatically when the last process in a cgroup exits, provided notify_on_release is set. The detail that turns this into a weapon is where that program runs. The release agent executes on the host, as root, outside the namespace of whatever process triggered it.
That behaviour has always been powerful, which is why writing to the release_agent file is supposed to require the kind of privilege a properly confined container does not have. The bug in CVE-2022-0492 is that the kernel failed to check capabilities correctly across namespace boundaries before permitting that write. In effect, a process that should not have been trusted to set a host-level release agent was allowed to do so anyway. Point the agent at a script of the attacker’s choosing, empty the cgroup, and the kernel obligingly runs that script as root on the host. The boundary holds right up until it is asked to do the one thing it was supposed to prevent.
What made this CVE notable in 2022, and what makes it worth re-assessing now, is the second route. Earlier release_agent escapes required a container to hold the CAP_SYS_ADMIN capability — a configuration most teams already knew to avoid. CVE-2022-0492 demonstrated that the same outcome could be reached by creating a new user namespace, undercutting the assumption that an unprivileged container was safe by default. The technique is publicly documented and well understood; this analysis stays deliberately at the mechanism level rather than the reproducer level, because the defensive takeaways do not require the latter.
This is where signal matters more than severity branding. The default Docker seccomp profile blocks the system calls the escape relies on. The default AppArmor and SELinux policies prevent the cgroupfs mount it needs. With any one of those enforcing, exploitation fails — which is why a flaw rated High has nonetheless sat quietly for four years. The exposed population is specific, and worth naming precisely.
The systems genuinely at risk are those still running cgroups v1 (cgroups v2 removed the release_agent mechanism entirely and is not affected); containers run with confinement deliberately stripped — --privileged, seccomp=unconfined, or AppArmor/SELinux disabled, common in CI runners, GPU and device-passthrough workloads, and “it wouldn’t work otherwise” troubleshooting that quietly became permanent; neglected host kernels, where image patching is disciplined but the host kernel has not been updated or rebooted in years; and embedded, appliance, IoT, and air-gapped systems with vendor-locked kernels that never received the 2022 backport.
A kernel vulnerability is not remediated when the package updates. It is remediated when the host runs the patched kernel — which on most systems means a reboot. Long-lived container hosts are precisely the machines operators are most reluctant to reboot, which is how a four-year-old “fixed” CVE remains live in production. uname -r tells you the running kernel; the installed package version does not.
This is not the first time CISA’s KEV catalog has surfaced a vulnerability whose disclosure date is years in the past, and the pattern is worth treating as a standing lesson rather than a curiosity. Active exploitation is not the exclusive domain of fresh zero-days. Attackers are pragmatic: a four-year-old flaw with public write-ups, against a population of hosts that demonstrably never patched, is a more reliable bet than a novel exploit against a hardened target. The KEV addition is a statement about the defender population as much as about the bug.
It also reflects a real shift in where the attack surface lives. Container adoption has outpaced container host hygiene in many organisations. The mental model that “patching” means updating images and pulling new base layers has quietly left the underlying kernel out of the loop. CVE-2022-0492 is a precise probe for that gap, and its reappearance suggests adversaries have noticed how common the gap still is.
“A container is not a virtual machine. It is a process on the host kernel, fenced in by a stack of separate defences — and CVE-2022-0492 is a probe for the seams between them.”
— Analysis of Unit 42 and Sysdig technical reporting on CVE-2022-0492The remediation here is well within reach of existing controls. The work is in verification, not in novel tooling.
uname -r against your distribution’s fixed version and schedule reboots for any host still on a pre-patch kernel. This is the actual fix; everything below is defence in depth.
release_agent feature and closes this class of escape outright. If your hosts still run v1, use this KEV addition as the forcing function — the security benefits extend well beyond this single CVE.
--privileged, with seccomp=unconfined, or with AppArmor/SELinux disabled. Each is a deliberate hole in the layered model. Treat “it only works unconfined” as a finding to resolve, not a config to keep.
release_agent files, unexpected cgroupfs mounts from inside a container, and new user-namespace creation by workloads with no reason to do so are all observable with eBPF-based tooling (Falco or equivalent) — high-fidelity signals for this technique.
The instructive part of CVE-2022-0492 is not the kernel mechanics. It is the gap between how container isolation is imagined and how it actually holds together. Teams tend to think of “the container” as a single boundary with a binary state — isolated or not. In reality it is a set of independent defences, each removing a class of attack, and the security of the whole degrades quietly as exceptions are carved into individual layers. A privileged flag here, a disabled profile there, a host kernel left unrebooted for a year: none of them feels like a breach of isolation at the time. Together they reconstitute the exact conditions this flaw needs.
The KEV deadline is June 5, but the deadline is the least interesting thing about this entry. The durable takeaway is that container hosts are first-class infrastructure and deserve the same patch discipline, kernel currency, and reboot cadence as any other production system. The attackers exploiting this flaw are not breaking new ground — they are walking through a door that was patched in 2022 and propped back open by operational drift. As is so often the case, the exploit is clever and the defence is not. It is verification, applied to the systems everyone assumed were already fine.
If you find ByteVanguard useful, you can support the site and help keep the analysis independent.
Support the analysis