Windows CLFS CVE-2026-40407

Requires the attacker to already have local, authenticated code-execution on the target as at least a low-privileged user (CVSS PR:L, AV:L) - this is a post-access privilege-escalation bug, not a remote or unauthenticated one. No special product configuration is needed because CLFS (clfs.sys) is enabled by default on every affected Windows client and server edition, and no user interaction is required (UI:N). Limiting factors: the attacker must first obtain local execution, cannot trigger it over the network, and unpatched vulnerable builds must be present; there is no evidence of active exploitation (SSVC Exploitation:none, not in KEV, EPSS 0.04%) and SSVC rates it non-automatable, so realistic use is targeted/manual chaining rather than mass exploitation.

The signals are internally consistent and point to a genuine but non-emergency local EoP. The CVSS vector (AV:L/AC:L/PR:L/UI:N) shows an attacker needs local access and low existing privileges, with no user interaction, yielding high confidentiality, integrity, and availability impact - a classic SYSTEM-escalation profile. CISA SSVC agrees on 'total' technical impact but marks Exploitation:none and Automatable:no, and EPSS is only 0.04% (13th percentile), so this is not currently seeing mass exploitation. It is NOT in CISA KEV, and no public exploit was identified at time of analysis. The primary risk driver is prevalence: CLFS is present on essentially every Windows host, and this driver class has a strong historical track record of being weaponized post-disclosure (multiple prior CLFS EoP bugs reached KEV). Prioritize patching in the normal-to-expedited window for a local EoP, especially on multi-user or shared systems, but this is a chained/post-compromise privilege bug, not a remote entry point.

An attacker who already has a foothold as a standard (low-privileged) user - for example via phishing, a compromised service account, or an initial RCE bug - runs a crafted program that submits malformed data to the CLFS driver, triggering the heap overflow and corrupting kernel memory to execute code as SYSTEM. No user interaction is needed and complexity is low, making it a reliable second-stage escalation once local access exists. No public exploit was identified at time of analysis, though CLFS EoP bugs have historically been weaponized quickly.