
The vulnerability was discovered by Ricardo Narvaja of Fortra during CLFS-focused vulnerability research and has been classified as a Denial-of-Service (DoS) flaw with a CVSS base score of 5.5.
The vulnerability stems from improper flag validation within the CLFS!CClfsRequest::ReadLogPagingIo function inside CLFS.sys (tested on version 10.0.22621.5037).
When a specific sequence of Windows API calls is made, the CLFS driver processes an I/O Request Packet (IRP) with critical flags in a disabled state, triggering a logic path that directly invokes nt!KeBugCheckEx Windows’ kernel-level panic handler places the system in an irreversible crash state.
The two key flags involved are:
- IRP_PAGING_IO (0x02): Signals that the I/O request relates to memory paging operations, such as paging file or memory-mapped file access.
- IRP_INPUT_OPERATION: Indicates that the I/O operation involves input data transfer, such as reading from a device or file.
For ReadLogPagingIo to process a request correctly, at least one of these flags must be enabled. In the PoC scenario, both flags were disabled (AL = 0x0), causing the driver to follow an incorrect execution path.
The internal flag value 0x42 tested during research had no documented behavior from Microsoft, highlighting a gap in public kernel documentation.
The BSoD crash chain is deterministic and begins from user-space with a standard ReadFile API call. The full kernel call stack captured during exploitation is:
textnt!DbgBreakPointWithStatus
nt!KiBugCheckDebugBreak+0x12
nt!KeBugCheck2+0xba3
nt!KeBugCheckEx+0x107
CLFS!CClfsRequest::ReadLogPagingIo+0xfc2f
CLFS!CClfsRequest::Dispatch+0x9c
CLFS!ClfsDispatchIoRequest+0x8e
CLFS!CClfsDriver::LogIoDispatch+0x27
nt!IofCallDriver+0x55
nt!IopSynchronousServiceTail+0x46f
nt!IopReadFile+0x4d4
nt!NtReadFile+0xdb
The call originates from KERNELBASE!ReadFile, which triggers nt!NtReadFile, escalating through the CLFS dispatch chain until the driver’s inconsistent state invokes KeBugCheckEx. The entire chain is reproducible without elevated privileges, making this particularly dangerous in multi-user or shared enterprise environments.
The PoC requires only two API calls and involves no crafted binary files or heap spray techniques. The attack sequence uses CreateLogFile to obtain a valid .blf log file handle, followed immediately by a ReadFile call on that same handle.
This call combination is inherently unexpected by the CLFS driver subsystem. Since ReadFile is not designed to operate on CLFS log handles in this context, the driver fails to handle the request gracefully and instead cascades into a kernel panic.
The simplicity of this PoC lowers the exploitation barrier significantly, meaning even a script-kiddie-level threat actor could deploy it as a disruptive denial-of-service tool in enterprise Windows environments.
Ricardo Narvaja of Fortra added that Microsoft silently fixed this vulnerability as part of the September 2025 cumulative update for Windows 11 2024 LTSC and Windows Server 2025. Windows 25H2, released in September 2025, shipped with the fix already included. However, Windows 11 23H2 and all earlier versions remain unpatched and are currently vulnerable.
This follows a pattern of recurring CLFS driver vulnerabilities that have plagued Windows for years, including CVE-2022-37969, CVE-2023-28252, CVE-2024-6768, and the actively ransomware-exploited CVE-2025-29824, all rooted in the same CLFS.sys driver subsystem.
Mitigation Recommendations
- Apply September 2025 or later cumulative updates for all Windows 11 and Windows Server 2025 deployments immediately.
- Upgrade to Windows 11 2024 LTSC or Windows 25H2 on supported hardware to ensure the fix is present.
- Restrict local logon access on sensitive systems to reduce the attack surface, given the local (AV:L) attack vector.
- Monitor for anomalous CLFS API calls, such as
ReadFileinvocations against log file handles, which are not standard operational patterns. - Audit and prioritize patching on multi-user environments, kiosks, and enterprise workstations where low-privileged accounts are active.
Organizations running unpatched Windows 11 23H2 or older builds should treat this as a high-priority patching action, particularly in environments where system availability is critical and local user access cannot be fully restricted.
Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.
The post PoC Released for Windows Vulnerability That Allows Attackers to Cause Unrecoverable BSOD Crashes appeared first on Cyber Security News.
Discover more from RSS Feeds Cloud
Subscribe to get the latest posts sent to your email.
