Yes. CISA added CVE-2022-0492 to its Known Exploited Vulnerabilities catalogue on 2 June 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Linux Kernel contains an improper authentication vulnerability which could allow for privilege escalation via the cgroups v1 release_agent feature. Any organisation running the affected product should treat remediation as urgent.
What “being exploited in the wild” means for this CVE
For a CVE question like this, the practical answer is not just whether a flaw exists, but whether it has moved from a theoretical issue to an active response priority. Once CISA places a CVE in the KEV catalogue, defenders should treat it as confirmed exploited, scope exposure quickly, and move it ahead of routine patch queues. Track the advisory and catalogue entry rather than relying on secondary summaries.
CVE records and KEV entries answer different questions. The CVE record identifies the vulnerability, while the KEV catalogue signals that defenders should assume real-world abuse is already happening and that delayed remediation increases exposure. For ongoing reference, use the CVE Program and the CISA Known Exploited Vulnerabilities Catalog.
For Linux kernel issues, the security question is often less about the kernel as a label and more about whether the vulnerable feature is present, reachable, and capable of being used for privilege escalation. In this case, the cgroups v1 release_agent path is the key condition to examine, because the exploit path depends on that feature being available in the environment.
Why this kernel flaw matters operationally
An improper authentication issue in the kernel matters because kernel-level compromise usually turns into full host compromise. That changes the incident from a contained application problem into a platform problem, with broad impact on local privilege boundaries, service isolation, and any workloads sharing the host. When the affected product is the operating system kernel, remediation urgency is usually high because the blast radius is the entire system.
If the vulnerable condition is exposed on a production host, the practical consequence is privilege escalation rather than mere service degradation. That means an attacker who gains a foothold through another weakness, stolen access, or local execution may be able to convert limited access into administrative control. For defenders, that makes exposure review and patch verification more important than waiting for observable signs of abuse.
For Linux hardening in general, the right baseline matters because configuration choices can remove or reduce the attack path that an exploit depends on. The Linux Server Hardening Guide is a useful reference for tightening host settings around kernel-adjacent controls, logging, and system hardening.
What to check, patch, and validate first
Start by confirming whether any asset actually runs the affected kernel path and whether the vulnerable feature is enabled in a way that matters to your deployment. Inventory is the first control point: if you do not know where the kernel version and configuration are in use, you cannot prove exposure or close it decisively.
Then apply the vendor fix or mitigation as soon as the maintenance window allows, and treat temporary deferral as an exception that needs explicit ownership. Where patching must wait, reduce exposure by removing unnecessary local access, tightening privileged execution paths, and validating whether the host is already used in a way that makes privilege escalation especially consequential.
Because CISA KEV inclusion indicates active exploitation, do not stop at installation state alone. Verify that the vulnerable kernel is no longer present, and check whether the host shows signs of prior compromise before or during remediation. If the system could have been used for privilege escalation, the remediation plan should include credential and session review for any accounts that had elevated access on that host.
The best way to operationalise this class of issue is with a formal vulnerability triage path that distinguishes exposure, exploitability, and remediation urgency. The Zero-Day and Exploited Vulnerabilities Guide helps structure that response, and the Vulnerability Management Guide supports the asset-scope and prioritisation work needed to close it cleanly.
Risk and Threat Considerations
This flaw is risky because exploitation can convert a normal Linux foothold into elevated control over the host. The danger is not limited to the vulnerable machine itself, since kernel compromise can undermine trust in the system, the workloads on it, and the access that was used to manage it.
Failure mechanism: An attacker reaches a host with some level of execution, abuses the improper authentication path in the kernel, and escalates privileges through the cgroups v1 release_agent feature.
Impact: The attacker may gain root-level control, tamper with local defenses, steal secrets, move laterally, or use the host as a stepping stone for broader compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Kernel CVEs require rapid remediation and verification of affected hosts. |
| RA-5 — Vulnerability Monitoring and Scanning | Exposure must be found quickly across hosts and configurations. | |
| Recommendation — Prioritise and verify remediation for the affected Linux kernel flaw as soon as exposure is confirmed. Scan assets to identify vulnerable kernel exposure and track remediation status until closure. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Active exploitation requires accelerated vulnerability triage and exception handling. |
| Recommendation — Triage the CVE as an emergency vulnerability and accelerate remediation across all affected hosts. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | The issue is a technical vulnerability needing controlled identification and remediation. |
| Recommendation — Manage the kernel flaw through formal vulnerability handling, exception tracking, and closure evidence. | ||
| MITRE ATT&CK | T1068 — Exploitation for Privilege Escalation | The described abuse path is privilege escalation through exploitation. |
| Recommendation — Map telemetry for privilege-escalation activity and hunt for exploitation of the kernel path. | ||
Practitioner Guidance
What to prioritise: Put exposed Linux hosts into an emergency inventory, then sort them by internet exposure, privileged access concentration, and business criticality. If the host can process sensitive workloads or administer other systems, treat the kernel issue as a containment problem, not only a patching problem.
What to verify: Confirm the exact kernel exposure, whether cgroups v1 is present in a meaningful configuration, and whether any privileged sessions or service credentials were active on the host around the time of possible exploitation. A patched system that was compromised before remediation still needs investigation.
Practitioner takeaway: For KEV-listed kernel flaws, the decision is usually about speed and certainty, patch quickly, then prove the host was not already used as a privilege-escalation point.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2022-0492 (Linux Kernel Improper Authentication)?
- CVE-2022-0492 (Linux Kernel Improper Authentication)
- Is CVE-2022-0995 (Linux Kernel Out-of-Bounds Write) being exploited in the wild?
- Is CVE-2023-0386 (Linux Kernel Improper Ownership Management) being exploited in the wild?