Is CVE-2022-0185 (Linux Kernel Heap-Based Buffer Overflow) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2022-0185 to its Known Exploited Vulnerabilities catalogue on 21 August 2024, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Linux kernel contains a heap-based buffer overflow vulnerability in the legacy_parse_param function in the Filesystem Context functionality. Any organisation running the affected product should treat remediation as urgent.

What “being exploited in the wild” means for this CVE

This is not a theoretical Linux kernel bug. For a practitioner, “exploited in the wild” means you should assume attacker interest, active targeting, and a short window between disclosure and abuse. The practical question is no longer whether exploitation is possible, but whether any exposed Linux hosts still carry the vulnerable kernel path and whether they have already been touched.

Because the flaw is in kernel code, the blast radius is high even when the initial entry point seems narrow. If a system is reachable and unpatched, kernel memory corruption can turn a local foothold into broader control, so exposure assessment should happen alongside normal patch triage, not after it.

For version and remediation specifics, use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog rather than relying on secondary summaries.

How to confirm whether you are exposed

Start by identifying every Linux system that could plausibly run the affected kernel path, including servers, appliances, containers with host access, and cloud instances that are not covered by a single patch-management workflow. The key issue is not just whether the package is installed, but whether the running kernel and deployed lifecycle actually match the vulnerable condition.

Use asset inventory, package records, and runtime validation together. A clean software catalog is not enough if golden images, ephemeral hosts, or delayed reboots leave the old kernel active. If you cannot prove the running kernel state, treat the host as exposed until verified.

When you need a broader operating model for Linux remediation and hardening, the Linux Server Hardening Guide is the best internal starting point for baseline verification, secure configuration, and kernel-adjacent controls.

What to do while patching is in progress

Apply the vendor fix as soon as possible on all in-scope systems, then force the operational step that often gets missed, which is the reboot or restart needed to put the patched kernel into service. On Linux, “patched” and “running the patched code” are not always the same thing.

If you cannot patch immediately, reduce the attack surface by limiting interactive shell access, constraining who can run privileged commands, and tightening monitoring on hosts that remain exposed. That does not remove the vulnerability, but it can reduce the chance that a local foothold becomes a full system compromise before remediation lands.

Use the Zero-Day and Exploited Vulnerabilities Guide and the Vulnerability Management Guide to align emergency triage, verification, and remediation tracking with your existing process.

Risk and Threat Considerations

This type of kernel flaw is attractive because it sits below many application-layer controls. Once exploited, the attacker may be able to escape the usual trust assumptions around user-space hardening, making the system more difficult to contain than an ordinary application bug.

Failure mechanism: A memory corruption condition in kernel code can be triggered by an attacker who reaches the vulnerable execution path, potentially enabling privilege escalation or deeper system compromise before normal controls can intervene.

Impact: The result can be host takeover, persistence, tampering with logs or security tooling, and downstream exposure of adjacent systems that trust the compromised Linux node.

When Linux exploitation is the concern, the CWE Top 25 Guide is useful for understanding how buffer overflow classes map to defensive prioritisation and root-cause analysis.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes vulnerability tracking and rapid remediation central.
Recommendation — Prioritise, remediate, and verify this CVE through continuous vulnerability management.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE requires timely flaw remediation and validated deployment on Linux hosts.
	SI-4 — System Monitoring	Exploited kernel flaws warrant monitoring for compromise indicators and abnormal host behaviour.
	CM-2 — Baseline Configuration	Kernel exposure depends on whether the running host baseline matches the fixed configuration.
Recommendation — Patch the vulnerable kernel promptly and verify the remediation is actually running. Increase host monitoring for signs of exploitation and post-exploitation activity. Maintain and validate a secure Linux baseline that removes vulnerable kernel states.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Recorded	Exposure assessment requires knowing which Linux assets still carry the vulnerable path.
Recommendation — Identify and record every Linux asset that may still run the vulnerable kernel.

Practitioner Guidance

What to prioritise: Patch or mitigate the hosts that are externally reachable, multi-tenant, or operationally critical first, then verify which systems actually rebooted into the fixed kernel. If you have to sequence the work, prioritize the systems where a local compromise would create the biggest blast radius.

What to verify: Confirm the running kernel version, not just the installed package state, and check for signs of suspicious privilege escalation, unexpected process activity, or post-exploitation tooling on any host that may have been exposed. If there is any doubt about prior compromise, treat that as an investigation problem, not only a patching problem.

Practitioner takeaway: For a KEV-listed Linux kernel flaw, the safe assumption is active exploitation pressure plus possible local escalation, so remediation should be verified in the running state and paired with compromise checks, not treated as a routine patch.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org