Six zero-days in three years: the CLFS pattern Microsoft can't outrun

The patch that shipped half-finished

On April 8, 2025, Microsoft patched CVE-2025-29824, a use-after-free in the CLFS driver, for Windows 11 and Windows Server. Windows 10 got nothing. The Windows 10 fix arrived on May 13, five weeks later, as KB5058379. Between those dates: active exploitation by two ransomware groups, a CISA KEV deadline of April 29 that Windows 10 shops could not meet with a vendor-supplied patch, and the quiet admission that one OS version matters more to Microsoft’s engineering calendar than the other.

Then KB5058379 caused lsass.exe crashes on systems with Intel vPro/TXT enabled, requiring an out-of-band follow-up. Depending on your hardware mix, the actual remediation window stretched to six or seven weeks.

This is CVE-2025-29824 in isolation: CVSS 7.8, local privilege escalation from standard user to SYSTEM, CISA KEV on day one. But isolation is the wrong frame. This is the sixth CLFS zero-day weaponized for ransomware since April 2022.

The pattern

Since April 2022, Microsoft has patched more than 32 elevation-of-privilege vulnerabilities in the CLFS driver, roughly ten per year. Six were confirmed exploited as zero-days before a patch existed:

• CVE-2022-24521 (April 2022)
• CVE-2022-37969 (September 2022)
• CVE-2023-23376 (February 2023)
• CVE-2023-28252 (April 2023, Nokoyawa ransomware)
• CVE-2024-49138 (December 2024)
• CVE-2025-29824 (April 2025, RansomEXX + Play ransomware)

The cadence isn’t slowing. In May 2025, Microsoft patched two more CLFS vulnerabilities: CVE-2025-32701, another confirmed zero-day, and CVE-2025-32706. At this rate, CLFS produces a weaponized zero-day about every six months. The pattern is so regular it could have a release schedule.

Why attackers keep choosing CLFS over other kernel targets is a structural question with a structural answer. CLFS uses a complex binary format (BLF files) that gets parsed in kernel mode with user-controlled input. It ships on every Windows installation going back to Server 2003. A single exploit works across all supported Windows versions without modification. For a ransomware operator who needs reliable SYSTEM access after landing on a machine, CLFS is the most cost-effective target in the Windows kernel.

Kaspersky’s GReAT team published analysis in late 2023 noting stylistic fingerprints across multiple CLFS exploits that suggested a single exploit author or supplier. Microsoft’s own April 2025 disclosure noted that “exploits may have been available to multiple threat actors before it was fixed.” Both observations point in the same direction: CLFS exploits aren’t being independently discovered by each ransomware group. They’re being developed and sold. A single vulnerability class, in a single driver, is sustaining what looks like a wholesale market for privilege escalation.

The evidence

CVE-2025-29824 is a reference count mismanagement in CClfsLogCcb, leading to a use-after-free (CWE-416). A standard user triggers the UAF, gains kernel-mode write primitives, escalates to SYSTEM.

Two distinct threat actors exploited it before the April 8 patch. They share nothing except the kernel exploit, which tells you what the exploit is: inventory.

Storm-2460 used the PipeMagic backdoor to deploy the CLFS exploit, then dropped RansomEXX. Targets spanned IT and real estate firms in the US, a financial institution in Venezuela, a software company in Spain, and a retailer in Saudi Arabia. PipeMagic previously delivered CVE-2025-24983, a Win32k zero-day. Same pipeline, swappable kernel exploit. The privilege escalation step is a procurement decision, not a research project.

Balloonfly, the group behind Play ransomware, took a different path toward the same destination. They gained initial access through a Cisco ASA appliance, then deployed the CLFS exploit disguised as legitimate Palo Alto Networks software (paloaltoconfig.exe and paloaltoconfig.dll). The observed intrusion stopped short of actual ransomware deployment, likely a reconnaissance phase or an interrupted operation, but the tooling (including the Grixba infostealer, seen exclusively in Play campaigns) left attribution beyond doubt.

Two different initial access vectors. Two different ransomware families. The same kernel driver exploit. The exploit is the commodity; everything around it varies.

The architectural fix, and its gap

Microsoft recognized the pattern. In late 2024, they shipped an architectural mitigation: HMAC-based authentication for CLFS log files. SHA-256 HMACs in a Merkle tree structure, system-unique key stored in kernel memory. The goal is to make BLF file tampering detectable before the parser touches it, cutting off the entire class of corruption-based attacks.

On Windows 11 24H2 and Server 2025, this is enabled by default. Microsoft confirmed that CVE-2025-29824 did not work on 24H2, for two reasons: HMAC validation caught the log file manipulation, and a separate hardening change requires SeDebugPrivilege for NtQuerySystemInformation calls, killing the address leak the exploit relied on. That is a genuine architectural improvement. It does not fix one bug; it makes the class detectable.

For older Windows, the HMAC mitigation is available as an optional rollout with a 90-day learn mode. Reasonable for a change that touches a core kernel subsystem. Less reasonable when you consider that Windows 10 didn’t even get the point fix for five weeks, let alone the class-level mitigation. The gap between “available” and “applied” is where the next CLFS exploit will land.

What this means for prioritization

If you’re making the call on where to spend patching effort, the CLFS pattern tells you three things:

Windows 10 carries structural risk that Windows 11 24H2 does not. The HMAC mitigation makes the entire class of CLFS log corruption exploits detectable. Every month Windows 10 machines remain in production is another month they’re exposed to the next variant. Given the cadence of roughly two zero-days per year, “the next one” is not hypothetical.

The five-week patch gap isn’t an anomaly to manage around. It’s a signal about where Windows 10 sits in Microsoft’s engineering priorities. When a zero-day is burning and one OS version gets a patch five weeks before another, that’s a prioritization decision on Microsoft’s part. Your fleet planning should account for it.

CLFS exploits are a commodity, not a capability. Two unrelated ransomware operations using the same exploit before the patch dropped is strong evidence that CLFS exploits are being traded. The implication for threat modeling: you don’t need to be targeted by a sophisticated actor to encounter a CLFS exploit. Any ransomware group with a budget can acquire one.

For environments still running mixed Windows 10/11 fleets, the practical move is to accelerate 24H2 deployment on endpoints where it’s feasible and ensure the HMAC opt-in is enabled on everything that can’t be upgraded yet. The 90-day learn mode exists for a reason; start the clock now rather than after the seventh zero-day.

What to watch

The CLFS pattern either stabilizes or it doesn’t. Two signals would confirm the fix is working: a decline in CLFS zero-days on 24H2-only targets, and attacker migration toward other kernel subsystems. Two signals would indicate it isn’t enough: CLFS exploits that bypass HMAC validation, or continued exploitation on the massive installed base that hasn’t adopted the mitigation.

The May 2025 CLFS patches, particularly CVE-2025-32701 as another confirmed zero-day, suggest the transition period isn’t over. The question that matters for fleet planning is whether CVE-2025-32701’s exploitation report includes a 24H2 exception. If it does, the HMAC mitigation is holding and the upgrade case writes itself. If it doesn’t, we’re back to counting zero-days. The current count is seven.

PatchDay Alert tracks the CLFS cadence across daily digests because the individual CVEs age out of the news cycle faster than the underlying pattern changes. The pattern is what matters for planning. The CVEs are just the timestamps.