Is CVE-2022-2586 (Linux Kernel Use-After-Free) being exploited in the wild?

Yes. CISA added CVE-2022-2586 to its Known Exploited Vulnerabilities catalogue on 26 June 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 use-after-free vulnerability in the nft_object, allowing local attackers to escalate privileges. Any organisation running the affected product should treat remediation as urgent.

What this means for Linux kernel exposure

CVE-2022-2586 is a kernel memory-safety issue, so the practical question is whether any Linux systems in your fleet actually run the vulnerable code path and can be reached by an attacker with local execution. A use-after-free in nft_object is especially important because it can turn a low-privilege foothold into privilege escalation, which changes it from a normal bug to a host takeover risk.

For teams that manage mixed Linux estates, the first pass is asset confirmation: identify kernel versions, hosted workloads, and any systems where local code execution is already plausible through users, containers, scheduled jobs, or exposed application tiers. If the vulnerable kernel is present, the issue is not theoretical, even if no outward symptom is visible.

One useful way to treat the problem is to start from the affected platform rather than the CVE label. The Linux Server Hardening Guide is useful here because kernel exposure is easier to manage when baseline hardening, firewalling, audit logging, and privilege boundaries are already in place.

Why active exploitation changes the response

Once a vulnerability is in CISA’s Known Exploited Vulnerabilities catalogue, it should be treated as more than a vulnerability-management item. The operational assumption changes from “patch when convenient” to “assume attackers may already be looking for this exact condition,” which makes exposure assessment and remediation prioritisation urgent.

For practitioners, that means the presence of active exploitation matters even if the observed business impact has not yet materialised. A kernel use-after-free can be used to convert ordinary local access into elevated control, and that kind of escalation often becomes the pivot point for further compromise, persistence, or tampering with host protections.

The strongest response pattern is to pair exploitability intelligence with prioritisation discipline. CISA Known Exploited Vulnerabilities Catalog should drive remediation urgency, while FIRST EPSS helps teams rank exposure when they are triaging a broader backlog of issues.

What to do when patching is not immediate

If the fix cannot be applied at once, the goal is to reduce the opportunity for local exploitation and preserve visibility on systems that still carry the risk. That means tightening where untrusted code can run, reducing unnecessary local access, and making sure kernel-level activity is logged well enough to support later compromise assessment if you need it.

Do not rely on “no obvious signs” as proof of safety. Kernel privilege-escalation bugs are often silent until they are used, and once they are used the same host may be trusted for too long by downstream tools, credentials, or adjacent systems.

Where vulnerability handling is already mature, the right workflow is to merge exposure checks, emergency remediation, and post-remediation verification into one process. The Zero-Day and Exploited Vulnerabilities Guide is a good fit for that workflow because it focuses on KEV-driven triage, emergency mitigation, and compromise assessment after patching.

Risk and Threat Considerations

Actively exploited kernel flaws are high-risk because they compress attacker effort: a local foothold can become elevated control before defenders have time to react. In practice, that means the vulnerability can be used to break the trust boundary between an ordinary process and the operating system itself.

Failure mechanism: A use-after-free in kernel object handling can let an attacker manipulate freed memory and steer execution toward privilege escalation or arbitrary kernel behaviour.

Impact: Once the kernel is compromised, the attacker may gain durable control of the host, disable protections, steal sensitive data, or use the machine as a launch point for broader intrusion.

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

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.AM-01 — Asset Inventory	Kernel exploitation response depends on knowing which Linux hosts are exposed.
Recommendation — Inventory all Linux systems running the affected kernel and track them to remediation.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed kernel flaws require continuous identification and prioritisation of exposed systems.
Recommendation — Prioritise and remediate exposed Linux hosts through continuous vulnerability management.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	A known exploited kernel use-after-free requires timely flaw remediation across affected systems.
	AU-2 — Audit Events	Host-level visibility matters when exploitation may be silent until privilege escalation succeeds.
Recommendation — Apply flaw remediation processes to patch or mitigate the vulnerable kernel promptly. Log kernel-relevant events needed to investigate local exploitation and follow-on activity.
MITRE ATT&CK	T1068 — Exploitation for Privilege Escalation	The CVE is a local kernel flaw that can be used to escalate privileges.
Recommendation — Hunt for privilege-escalation activity on hosts exposed to the vulnerable kernel.

Practitioner Guidance

What to verify: Confirm whether the vulnerable Linux kernel is present anywhere in production, in golden images, and in long-lived workloads that may have drifted from managed baselines. Verification should include virtual machines, bare metal, and container hosts, because the risk lives in the host kernel, not in the application stack alone.

Decision rule: If a system can be reached by an untrusted local user, shared job runner, developer shell, or compromised application account, treat remediation as urgent even before you have proof of exploitation. If patching is delayed, shorten the exposure window by reducing local access and increasing host monitoring until the fix is in place.

Practitioner takeaway: For a KEV-listed kernel flaw, the main decision is not whether the vulnerability is severe in theory, but whether any reachable host still allows an attacker to turn local access into kernel-level privilege before you remove the condition.