Yes. CISA added CVE-2025-38352 to its Known Exploited Vulnerabilities catalogue on 4 September 2025, 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 time-of-check time-of-use (TOCTOU) race condition vulnerability that has a high impact on confidentiality, integrity, and availability.
What CISA’s KEV listing means for CVE-2025-38352
A KEV listing is not just a theoretical signal. For this CVE, the practical meaning is that defenders should treat it as an active exploitation problem, not a routine patch-cycle item. The first question is whether any Linux systems are exposed to the affected kernel path, because confirmed exploitation changes urgency, testing order, and exception handling.
That makes this a prioritisation issue as much as a vulnerability issue. Once a kernel flaw is in KEV, organisations should assume opportunistic scanning and rapid follow-on abuse are plausible until systems are remediated or otherwise contained.
For teams building a response process, the Zero-Day and Exploited Vulnerabilities Guide is the most useful operating model here because it focuses on KEV triage, emergency mitigation and post-patch validation rather than abstract vulnerability theory.
Why a Linux kernel TOCTOU flaw is operationally serious
A time-of-check time-of-use race condition matters because the system validates one state and then acts on a different state. In kernel space, that gap can be abused to bypass intended security checks, create privilege misuse, or trigger actions that were never meant to be allowed.
The impact is usually not limited to a single bad request. Kernel race conditions can be repeated, tuned and combined with local access or other footholds to gain stronger control, widen blast radius, or persist longer than a simple application bug would allow.
At a broader control level, the CWE Top 25 Guide helps map this class of weakness to the underlying software flaw pattern, while the Linux Server Hardening Guide is relevant for reducing exposure around kernel-adjacent hardening, logging and baseline control.
External reference points also matter here: the CVE Program is the canonical identifier source, and the NIST National Vulnerability Database remains the place to verify record details and technical metadata as they evolve.
What defenders should do while verification and remediation are underway
The immediate response is to confirm whether any Linux hosts are actually running the affected kernel line and whether those hosts are internet-facing, multi-tenant, or otherwise high-value. If patching is delayed, the risk is not just exposure, it is the possibility that a known exploited flaw remains reachable long enough to be reused across multiple systems.
Where remediation must wait, the practical fallback is containment: narrow who can reach the affected systems, limit privileged interactive access, and increase monitoring for unusual kernel-adjacent behaviour, privilege changes, crashes or unexplained process activity. If the environment has evidence of suspicious activity, treat compromise assessment as part of the remediation path, not a separate project.
For ongoing prioritisation, the Vulnerability Management Guide is a useful companion because it frames KEV-driven prioritisation, exception handling and verification in operational terms. CISA’s Known Exploited Vulnerabilities Catalog should be checked directly for authoritative status and action timing, while the FIRST EPSS service can add context when teams need to rank this alongside other active risks.
Risk and Threat Considerations
This vulnerability combines two risk drivers: a kernel-level race condition and confirmed in-the-wild exploitation. That makes it more likely to be used for rapid compromise, especially where Linux hosts are exposed, poorly segmented, or slow to patch.
Failure mechanism: An attacker or local user can exploit the TOCTOU gap by causing the checked state to differ from the used state, defeating intended security logic and enabling unsafe kernel behaviour.
Impact: The result can be privilege abuse, integrity loss, confidentiality exposure, service disruption, or a foothold for broader compromise if the flaw is successfully chained with other access paths.
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, NIST CSF 2.0 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 | KEV-listed kernel flaws require continuous identification and prioritisation of exploitable weaknesses. |
| Recommendation — Prioritise and remediate KEV-listed Linux kernel vulnerabilities through continuous vulnerability management. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerabilities Are Identified and Documented | Exposure assessment depends on knowing which Linux assets run the vulnerable kernel. |
| PR.IP-12 — Vulnerability Mitigation | A confirmed exploited kernel flaw requires rapid mitigation and remediation steps. | |
| Recommendation — Identify affected Linux assets and document exposure before selecting containment or patch actions. Apply mitigation and remediation actions quickly for the affected kernel vulnerability. | ||
| MITRE ATT&CK | T1068 — Exploitation for Privilege Escalation | Kernel race conditions are commonly abused to elevate privileges after initial access. |
| Recommendation — Hunt for privilege-escalation activity consistent with exploitation of the kernel flaw. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The issue is an actively exploited software flaw that requires remediation tracking and execution. |
| Recommendation — Track, patch, and verify remediation of the exploited Linux kernel flaw. | ||
Practitioner Guidance
What to prioritise: Treat any exposed Linux host as a high-priority asset if it is reachable and not yet verified as remediated. Prioritise systems that host shared workloads, privileged services or sensitive data, because the consequence of kernel-level abuse is typically much larger than the vulnerability entry itself suggests.
What to verify: Confirm kernel version, exposure path, patch state and whether there are signs of abnormal privilege-related activity. If you cannot patch immediately, document the exception with a time bound and a compensating control that actually reduces reachable attack surface.
Practitioner takeaway: For KEV-listed kernel flaws, the right question is not whether exploitation is possible in theory, but whether the vulnerable path is still reachable long enough to matter.
Related resources from NHI Mgmt Group
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.
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