Old CVEs Still Being Exploited: CVE-2022-0492, Linux Kernel cgroups, Still Active in 2026

CVE Summary

Field	Details
CVE ID / CVSS Score	CVE-2022-0492, commonly listed at 7.0 (High) at original 2022 disclosure, with 7.8 (High) cited in current NVD and third-party aggregator listings
Affected Product / Vendor	Linux kernel, cgroups v1 subsystem (open source, maintained by the Linux kernel community and packaged by all major distributions)
Vulnerability Class / CWE	Improper Authentication and Missing Authorization, CWE-287 and CWE-862
Original Disclosure Date	February 4, 2022
Years Since Disclosure	Approximately 4 years
Current Exploitation Status	Actively exploited. Added to CISA's Known Exploited Vulnerabilities catalog on June 2, 2026.
Associated Threat Actors	None publicly named at the time of the 2026 catalog addition

Sourcing and Methodology Note

The original disclosure and patch history are established by the upstream kernel fix itself, commit 24f6008564183aa120d07c03d9289519c2fe02af, merged ahead of kernel 5.17-rc3, the February 4, 2022 oss-security mailing list disclosure by Tabitha Sable on behalf of discoverers Yiqi Sun and Kevin Wang of the Huawei Security Team, and 2022 technical write-ups from Palo Alto Networks Unit 42 and Sysdig, both of which documented the container escape mechanism and published proof-of-concept detail shortly after disclosure.

Confirmation that exploitation is happening now, not merely that the flaw remains theoretically exploitable, comes specifically from CISA's Known Exploited Vulnerabilities catalog addition on June 2, 2026, which required Federal Civilian Executive Branch agencies to remediate by June 5, 2026 based on evidence of active exploitation. That catalog addition, reported by The Hacker News, Security Affairs, VulnBrief, and Threat-Modeling.com, is the specific, dated evidence this post relies on for current activity, as distinct from the 2022 sources, which establish only that the flaw existed and was patched.

Introduction

CVE-2022-0492 is a Linux kernel container escape vulnerability that was patched more than four years ago, in February 2022. It should be ancient history. Instead, CISA added it to its Known Exploited Vulnerabilities catalog on June 2, 2026, confirming that it is being actively exploited against systems today, four years after a fix first became available. No threat actor has been publicly named in connection with this specific 2026 activity, which makes the persistence itself, rather than any single campaign, the real story here. Why is a fully patched, four-year-old kernel logic bug still a live threat in 2026? The answer has less to do with the vulnerability and more to do with how Linux distributions, container platforms, and kernel subsystems age.

Original Disclosure Context

CVE-2022-0492 was discovered by Yiqi Sun and Kevin Wang of the Huawei Security Team and disclosed to the Linux kernel community by Tabitha Sable on February 4, 2022, through the oss-security mailing list, alongside the upstream patch itself. The vulnerability received meaningful technical attention at the time from container security vendors, notably Palo Alto Networks Unit 42 and Sysdig, both of which published detailed write-ups explaining the container escape mechanism within days of disclosure. It was rated 7.0 on the CVSS scale at original disclosure, later reflected as 7.8 in some current listings, placing it in the high severity range without reaching critical. It was not added to CISA's Known Exploited Vulnerabilities catalog at the time of its 2022 disclosure, since no exploitation had been observed in the wild at that point; its addition came only in 2026.

Why This Vulnerability Persists

Several specific, evidenced mechanisms explain why this vulnerability is still relevant in 2026.

A logic bug, not a memory corruption bug. Exploitation requires no heap grooming, timing tricks, or kernel-build-specific offsets. It is a straightforward missing capability check, which keeps the skill bar to weaponize it extremely low and keeps existing public proof-of-concept code, including a ready-to-use Metasploit module, reliable across a wide range of kernel versions without needing updates.

End-of-life base images that cannot move to cgroups v2. The long-term fix for this entire class of exposure is migrating from cgroups v1 to cgroups v2, which removes the release_agent attack surface entirely. That migration has been slower than expected in practice. Amazon Linux 2, a widely used long-term-support base image, does not support cgroups v2 out of the box and remains supported through June 30, 2026, meaning any workload built on it cannot fully close this exposure without a base image migration, not just a kernel patch. Kubernetes itself only removed cgroups v1 support from the kubelet starting with version 1.35, which began rolling out to major managed Kubernetes services, including Google Kubernetes Engine, Amazon EKS, and Microsoft AKS, between March and September 2026, more than four years after this CVE was originally patched.

Containers still run more permissively than they should. Independent usage data from Sysdig's container security reporting has found that a majority of containers run as root by default, reflecting a broader pattern of containers being deployed with more privilege than necessary. Running as root is not identical to holding the privileged flag or SYS_ADMIN capability this specific CVE requires, but it reflects the same underlying tendency toward permissive default configurations that also leaves the privileged and SYS_ADMIN grants this vulnerability depends on more common than security best practice would recommend.

Low visibility into which hosts are still exposed. Because exploitation requires no network traffic and produces no obvious external signature, an organization that patched its container orchestration layer may not realize that specific legacy hosts, unmigrated base images, or forgotten standalone Docker hosts were never brought current, since there is no equivalent of an internet-wide Shodan scan that can identify vulnerable systems the way there is for network-facing CVEs.

Current Exploitation Activity

The concrete evidence of current activity is CISA's June 2, 2026 addition of CVE-2022-0492 to its Known Exploited Vulnerabilities catalog, with a remediation deadline of June 5, 2026 for federal agencies. At the time of that catalog update, no specific campaign details, targeted sectors, victim geography, or attack scale had been publicly disclosed alongside the addition. This is consistent with how CISA's catalog frequently operates: the addition itself is authoritative evidence that exploitation has been observed, even when the underlying campaign details remain undisclosed or are still under investigation.

Threat Actor Attribution

No threat actor, APT group, or ransomware operator has been publicly named in connection with the confirmed 2026 exploitation of CVE-2022-0492. This post states that plainly rather than speculating. Given the nature of the flaw, a generic privilege escalation technique usable against any host meeting the prerequisite conditions rather than a vulnerability in a specific named application, it is more consistent with opportunistic use by a range of actors, container-focused initial access brokers, cryptomining operations, or ransomware affiliates seeking to escalate from an existing container foothold, than with a single attributed campaign. No official source has characterized it either way as of this writing.

Exploitation Technique and Attack Chain

The exploitation technique itself has not changed since 2022, and public tooling, including a Metasploit module and multiple independent proof-of-concept repositories, has implemented it in essentially the same form throughout this vulnerability's history. An attacker who is already root inside a container running with the Docker privileged flag or the SYS_ADMIN capability mounts the cgroup filesystem, creates a cgroup, enables notify_on_release, determines the host filesystem path corresponding to the container's own overlay mount, writes an attacker-controlled payload to that host-visible path, and sets the cgroup's release_agent file to point at it. Emptying the cgroup, typically by writing to cgroup.procs, causes the kernel to execute the payload as root in the host's initial namespaces, completing the escape.

What has changed over time is not the technique but its context. As more organizations adopted AppArmor, SELinux, or Seccomp enforcement by default in mainstream container runtimes, the population of genuinely exploitable hosts narrowed to those that explicitly disable these protections or grant the privileged flag to bypass them, and to legacy hosts still running cgroups v1 without modern hardening. Rather than attackers adapting the exploit itself, the relevant adaptation has been on the defensive side, and the hosts still vulnerable in 2026 are disproportionately the ones that missed that broader hardening trend.

Affected Versions and Patch Status

The vulnerability affects Linux kernel versions 2.6.24 through 5.17-rc2, essentially the full history of the cgroups v1 subsystem prior to the fix, resolved in kernel 5.17-rc3. Debian, Red Hat, SUSE, Ubuntu, and Fedora all published corresponding security advisories and backported the fix within weeks of the February 2022 disclosure, so the patch itself has been broadly available for over four years. No network-facing scan methodology exists to estimate the current still-vulnerable population the way Shodan can for internet-exposed services, since this is a local, kernel-level vulnerability with no external signature. The best available proxy for ongoing exposure is infrastructure-level: Amazon Linux 2, which does not support cgroups v2 out of the box, remains under support through June 30, 2026, and Kubernetes only began enforcing a hard cutoff of cgroups v1 support starting with version 1.35 in 2026, both indicating that a meaningful population of hosts is still running cgroups v1 in production well after this CVE's patch became available.

MITRE ATT&CK Mapping

No named threat actor or attributed campaign has been publicly documented for the confirmed 2026 exploitation of this CVE, and no CISA-published, technique-level mapping specific to observed exploitation of CVE-2022-0492 was identified for this post. Stating that plainly is more accurate than filling this section with generic possibilities. The technique the vulnerability's mechanism corresponds to, MITRE ATT&CK's own Escape to Host technique, is documented by MITRE using cgroups release_agent abuse as an illustrative example of the technique's mechanism generally, not as a record of any specific observed campaign against this CVE:

Tactic	Technique	ID
Initial Access	Not applicable. This CVE requires an attacker to already hold root access inside a container; it does not itself provide initial access.
Execution	Not applicable. No technique-level source specific to observed exploitation of this CVE was identified for this stage.
Persistence	Not applicable. No technique-level source specific to observed exploitation of this CVE was identified for this stage.
Privilege Escalation	Escape to Host, the mechanism MITRE's own documentation associates with cgroups release_agent abuse generally	T1611
Defense Evasion	Not applicable. No technique-level source specific to observed exploitation of this CVE was identified for this stage.
Command and Control	Not applicable. No C2 component has been documented in connection with this CVE's exploitation.

Notable Recent Incidents

The specific, dated evidence available for this post is CISA's June 2, 2026 Known Exploited Vulnerabilities catalog addition itself, with its June 5, 2026 federal remediation deadline. No separately reported, named breach or incident disclosure specifically attributing a 2026 compromise to CVE-2022-0492 was identified. The catalog addition is the concrete fact available; it confirms exploitation occurred without providing the kind of individually reported incident detail available for higher-profile CVEs.

Risk Context for Organizations

This vulnerability matters most today for organizations running container infrastructure on legacy or unmigrated base images, particularly Amazon Linux 2 and other distributions that have not moved to cgroups v2, and for any environment that grants the Docker privileged flag or SYS_ADMIN capability without a strict, reviewed justification. Multi-tenant and shared container hosting is disproportionately at risk, since a single compromised or malicious tenant with privileged container access can use this flaw to compromise every other workload on the same host. Organizations that migrated their container orchestration layer but never audited standalone Docker hosts, older build servers, or CI/CD runners for the same exposure are a specific, easily overlooked risk category, since kernel-level fixes and container hardening policies do not always get applied consistently across every category of host in an environment.

Detection and Mitigation Considerations

Organizations should confirm kernel patch status against their specific distribution's advisory, since this is the definitive fix. Independent of patch status, AppArmor, SELinux, or Seccomp enforcement should be verified as active, not assumed, for every container, since these controls block this technique even on an unpatched kernel. Any container running with the privileged flag or SYS_ADMIN capability should be audited and that grant removed unless explicitly justified. Migration from cgroups v1 to cgroups v2 should be treated as a planned infrastructure project, particularly for organizations still running Amazon Linux 2 or similar images ahead of their support end dates, since Kubernetes's own 2026 removal of cgroups v1 support from the kubelet makes this migration unavoidable regardless of this specific CVE. For detection, security teams should monitor for unexpected writes to any cgroup's release_agent or notify_on_release files originating from inside a container namespace, and for unexpected root-privileged processes on the host tracing back to a container origin.

Key Takeaways

• CVE-2022-0492 is a Linux kernel cgroups v1 container escape, patched in February 2022, but confirmed by CISA as actively exploited as of June 2026, more than four years later.
• It persists because it is a simple, reliable logic bug with mature public tooling, because widely used base images like Amazon Linux 2 do not support cgroups v2 out of the box, and because container hardening controls that would block it are not consistently enforced.
• No threat actor has been publicly attributed to the confirmed 2026 exploitation, and this post states that plainly rather than speculating.
• The exploitation technique itself has not changed since 2022; what has changed is that the population of genuinely exploitable hosts has narrowed to those missing modern container hardening or still running legacy, unmigrated infrastructure.
• Organizations should verify kernel patch status, confirm AppArmor, SELinux, or Seccomp enforcement is active, audit privileged container grants, and treat migration to cgroups v2 as an infrastructure priority, not only a security patch.

Conclusion

CVE-2022-0492 illustrates a pattern that is easy to underestimate: a vulnerability does not need to be recently disclosed, or tied to a headline-grabbing threat actor, to remain dangerous. It needs only to sit in a code path that a meaningful number of organizations have not fully migrated away from, which cgroups v1 clearly still is more than four years after this specific fix and years into a broader, still-ongoing industry transition to cgroups v2. Well-known, well-patched vulnerabilities like this one often persist not because the fix was hard to apply, but because the surrounding infrastructure, legacy base images, unmigrated standalone hosts, and permissive container defaults, was never fully retired. CISA's 2026 confirmation is a reminder that "patched years ago" and "no longer exploitable in practice" are not the same claim.

Instantly Fix Risks with Saner Patch Management

Saner Patch Management is a continuous, automated, and integrated patch management solution that helps organizations rapidly remediate vulnerabilities actively exploited in the wild. It supports Windows, Linux, macOS, and more than 550 third-party applications, enabling timely deployment of security updates across enterprise environments.

The platform also provides safe patch testing environments, automated deployment workflows, compliance reporting, and patch rollback capabilities to minimize operational risk while ensuring critical vulnerabilities are addressed without delay.

Experience the fastest and most accurate patching software here.