When defenders think about actively exploited vulnerabilities, attention often shifts toward newly disclosed zero-days and the latest high-profile attacks. Yet some of the most dangerous vulnerabilities today are neither new nor particularly complex.
One such example is CVE-2022-0492, a Linux Kernel privilege escalation vulnerability that continues to appear in intrusion investigations years after its initial disclosure.
Despite being patched in 2022, the vulnerability was added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog on June 2, 2026, highlighting a reality security teams know all too well: attackers are still finding vulnerable systems.
And when the target is the Linux kernel itself, the consequences can be significant.
Overview #
CVE-2022-0492 is an Improper Authentication vulnerability (CWE-287) and Missing Authorization vulnerability (CWE-862) affecting Linux systems that utilize the cgroups v1 release_agent functionality.
The flaw allows an attacker who already has code execution within a containerized or restricted environment to potentially escalate privileges and execute code on the host operating system.
In simple terms, a compromise that was supposed to remain isolated can potentially break free of its containment.
That distinction makes this vulnerability particularly important in cloud-native and containerized environments.
Understanding cgroups and release_agent #
Control Groups, commonly known as cgroups, are a Linux kernel feature used to manage and limit system resources such as CPU, memory, and I/O utilization.
Container platforms rely heavily on cgroups to isolate workloads and enforce resource controls.
Within cgroups v1, a feature known as release_agent allows administrators to define a program that executes when a cgroup becomes empty.
Under normal circumstances this functionality is harmless.
However, CVE-2022-0492 stems from insufficient authorization checks surrounding modifications to the release_agent configuration.
An attacker capable of manipulating specific cgroup settings may be able to execute commands with elevated privileges outside the intended security boundary.
The result is a potential container escape and privilege escalation scenario.
Why This Vulnerability Matters #
Many organizations have become comfortable with the assumption that containers provide strong isolation.
While containers significantly improve security when configured correctly, they are not security boundaries in the same way that dedicated virtual machines are.
Kernel vulnerabilities remind us of this reality.
If an attacker gains access to a vulnerable container and can exploit a flaw within the underlying kernel, the isolation between container and host may disappear entirely.
Once host-level access is obtained, the attacker gains a far broader set of opportunities:
- Access to neighboring containers
- Credential theft
- Host system compromise
- Persistent malware deployment
- Lateral movement
- Cloud infrastructure abuse
In multi-tenant environments, the impact can extend far beyond a single workload.
A Common Attack Chain #
One of the reasons vulnerabilities like CVE-2022-0492 remain relevant is that they fit neatly into modern attack workflows.
A typical attack sequence may look like this:
- An attacker exploits a vulnerable web application running inside a container.
- Initial code execution is obtained.
- The attacker identifies a vulnerable Linux kernel.
- The cgroups release_agent feature is abused.
- Privileges are escalated beyond the container boundary.
- Host-level access is established.
- Additional containers and infrastructure are targeted.
In many incidents, the original application vulnerability becomes almost irrelevant after successful privilege escalation.
The kernel bug becomes the turning point that transforms a limited compromise into a full system breach.
Why Attackers Love Old Kernel Vulnerabilities #
There’s a common misconception that older vulnerabilities become less dangerous over time.
In reality, the opposite is often true.
Public exploit code becomes widely available.
Technical documentation improves.
Detection gaps become easier to identify.
Meanwhile, countless systems remain unpatched due to operational constraints, unsupported environments, or simple oversight.
Linux kernels are especially difficult to patch in some organizations because updates often require:
- Reboots
- Maintenance windows
- Application testing
- Change control approvals
As a result, vulnerabilities that should have disappeared years ago continue to surface during incident response investigations.
Container Security Lessons #
CVE-2022-0492 also highlights an important lesson regarding container security.
Many organizations focus almost exclusively on:
- Container image scanning
- Dependency vulnerabilities
- Application security
While those controls are important, the underlying host remains equally critical.
A perfectly secure container running on a vulnerable kernel is still at risk.
Security teams should regularly validate:
- Kernel patch levels
- Container runtime configurations
- Privileged container usage
- cgroups settings
- Namespace isolation controls
Defensive strategies that ignore the host operating system leave a significant attack surface exposed.
Detection and Threat Hunting #
Organizations should investigate for indicators that suggest abuse of cgroups functionality or unusual privilege escalation activity.
Potential indicators include:
- Unexpected modifications to release_agent settings
- Suspicious activity involving cgroups directories
- Privilege escalation events
- Container breakout attempts
- Unusual processes running as root
- Unexpected child processes spawned from containers
Security teams should also review:
- Container runtime logs
- Linux audit logs
- Endpoint telemetry
- Host process creation events
Because exploitation often occurs after initial access has already been obtained, defenders should focus on identifying attack chains rather than isolated events.
Mitigation Recommendations #
Organizations should review vendor guidance and verify whether affected Linux systems remain vulnerable.
Recommended actions include:
- Apply kernel updates containing the fix.
- Migrate away from cgroups v1 where feasible.
- Restrict privileged container usage.
- Implement container hardening controls.
- Monitor for suspicious cgroup modifications.
- Audit container runtime configurations.
- Validate host security baselines.
Cloud providers and managed platform vendors may also have separate guidance regarding affected environments.
Administrators should verify patch status rather than assuming managed services are protected.
Is Ransomware Involved? #
At the time of writing, there is no public reporting directly linking CVE-2022-0492 to ransomware campaigns.
However, the vulnerability provides capabilities commonly leveraged during ransomware intrusions.
Privilege escalation remains one of the most valuable objectives for threat actors because it enables:
- Defense evasion
- Credential theft
- Persistence
- Lateral movement
Whether the final payload is ransomware, espionage tooling, cryptominers, or data theft operations, the underlying objective remains largely the same: gain greater control over the environment.
Final Thoughts #
CVE-2022-0492 serves as another reminder that attackers do not distinguish between „new“ vulnerabilities and „old“ vulnerabilities.
They care about what works.
A kernel-level privilege escalation vulnerability that enables container escapes remains extremely valuable years after disclosure, particularly in environments where patching has fallen behind.
For defenders, the lesson is clear.
Container security cannot stop at the container boundary.
The host kernel remains one of the most critical components in the security stack, and when vulnerabilities emerge there, the consequences often extend far beyond a single application.
Four years after disclosure, CVE-2022-0492 is proving that some vulnerabilities have a much longer lifespan than many organizations would like to believe.