Is CVE-2022-0995 (Linux Kernel Out-of-Bounds Write) being exploited in the wild?

Yes. CISA added CVE-2022-0995 to its Known Exploited Vulnerabilities catalogue on 26 August 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 out-of-bounds memory write vulnerability which could allow a local user to gain privileged access or cause a denial of service on the system.

What the KEV listing means for real-world exploitation

CISA only adds a CVE to its Known Exploited Vulnerabilities catalogue when it has reliable evidence of active exploitation. For this Linux kernel flaw, that means the question is no longer hypothetical: it should be treated as an exploited vulnerability, not a theoretical weakness. The practical task is to confirm whether exposed Linux systems are in scope and whether any local privilege escalation path is present.

Because the issue is an out-of-bounds write in the kernel, the most important exposure question is whether an attacker can reach a vulnerable system with local execution. If they can, the likely payoff is privilege escalation or denial of service. That makes the vulnerability operationally important even when the initial foothold is small.

Teams tracking exploited Linux issues should use a guide to zero-day and actively exploited vulnerabilities to frame the response around confirmation, emergency mitigation, and post-fix validation rather than ordinary patch cadence.

For version and remediation details, the authoritative references remain the CISA Known Exploited Vulnerabilities Catalog and the CVE Program.

Why an out-of-bounds kernel write is high impact

An out-of-bounds write in the kernel is dangerous because the kernel sits at the boundary between user space and the most privileged code on the host. A successful write can corrupt memory, crash the system, or alter execution in ways that elevate privileges. Even when exploitation is not guaranteed on every build or deployment, the impact class is serious enough that exposure should be assumed material until proven otherwise.

The issue is especially relevant where Linux hosts run shared workloads, sensitive automation, or administrative tooling. Once a local user can convert a low-privilege session into privileged access, the flaw can become a pivot point for credential theft, persistence, or tampering with logs and security controls. That is why exploited kernel bugs often matter beyond the immediate host crash.

Kernel memory-safety issues also justify looking at the weakness class itself, not just the CVE record. The CWE Top 25 Guide is useful context for understanding how out-of-bounds memory errors map to recurring software weakness patterns and why they keep reappearing in privileged code.

When organisations need a broader hardening baseline for Linux fleets, the Linux Server Hardening Guide helps connect kernel risk to the surrounding controls that limit abuse after initial access.

What to do while you verify exposure and wait for remediation

The first step is to confirm whether any Linux systems in scope are actually running the affected kernel line, then identify which of them permit untrusted local users, container escape pathways, or other pathways that make local privilege escalation meaningful. If patching is delayed, the priority is to reduce the number of users and services that can trigger the vulnerable code path and to contain the blast radius of any successful local compromise.

Do not treat this as a patch-only event. Because CISA lists the vulnerability as actively exploited, teams should check for evidence of suspicious local activity, unexpected privilege changes, unusual kernel crashes, and post-exploitation behaviour such as altered cron jobs, new privileged users, or tampered audit logs. If those signals exist, incident response should move ahead of routine maintenance.

The response sequence is best handled through established vulnerability-management practice, especially verification, prioritisation, exception handling, and re-check after remediation. Vulnerability Management Guide is a practical reference for that workflow, particularly where exploit confirmation changes remediation urgency.

Where teams need to correlate this with wider exploitation patterns, NIST National Vulnerability Database provides canonical vulnerability record context, while the FIRST EPSS model helps prioritise by exploitation likelihood when many issues compete for attention.

Risk and Threat Considerations

The main risk is privilege escalation from local access, which can turn a routine foothold into full host control. Because the flaw is already in CISA’s exploited list, defenders should assume that opportunistic exploitation is plausible and that exposed systems may be targeted quickly after disclosure or after the vulnerability becomes practical to weaponise.

Failure mechanism: An out-of-bounds write in kernel memory can corrupt execution state, crash the system, or allow an attacker with local code execution to gain privileged access.

Impact: Successful exploitation can lead to full system compromise, denial of service, tampering with security controls, and follow-on movement if the host is a stepping stone to other assets.

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 and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited CVEs require prioritized exposure verification and remediation.
	CIS-18 — Penetration Testing	Validate whether local exploitation paths exist and whether controls block escalation.
Recommendation — Prioritise and track remediation for exposed Linux hosts before routine backlog work. Test whether local user paths can still reach privileged kernel behaviour.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Kernel vulnerabilities require timely identification, patching and exception handling.
	SI-4 — System Monitoring	Active exploitation warrants monitoring for local compromise and post-exploit behaviour.
Recommendation — Patch or mitigate the vulnerable kernel and document any accepted delay. Monitor affected Linux hosts for crash, privilege-escalation and tampering indicators.
MITRE ATT&CK	T1068 — Exploitation for Privilege Escalation	The flaw can let a local user gain privileged access through kernel memory corruption.
Recommendation — Hunt for privilege-escalation activity on hosts with local access paths.

Practitioner Guidance

What to verify: Confirm which Linux hosts are exposed, whether the vulnerable kernel is present, and whether any local access paths make escalation credible. If a host is internet-facing, multi-tenant, or used for sensitive admin functions, treat exposure as higher urgency.

Decision rule: If you cannot patch immediately, reduce local access, isolate the host where feasible, and hunt for signs of prior compromise before you defer remediation. If the system already shows suspicious privilege changes or unexpected kernel instability, move straight to incident response.

Practitioner takeaway: Act on this as an exploited kernel weakness, not just a CVE record, because the operational question is whether a low-privilege local foothold can become privileged control before you finish normal patch cycles.