SignDrop turns Microsoft's October CLFS fix into SYSTEM escalation

Microsoft shipped a mitigation in October 2025 to defend the Common Log File System (CLFS) driver against a class of authentication attacks, and by the account of the researcher who broke it, it worked. Exploitation of CLFS vulnerabilities dropped sharply afterward. The zero-day he has now released, SignDrop, turns that mitigation into a local privilege escalation to SYSTEM.

Abdelhamid Naceri, who publishes as Nightmare Eclipse, says the flaw sits in how CLFS creates the authentication file, “.cnpf”, that the October mitigation introduced. CLFS writes that file whenever it creates a new log file, and it runs the access checks correctly at that point. The gap opens later. If a different, privileged process opens the log file, CLFS creates the authentication file in that process’s context, with SYSTEM privileges, and applies the original file’s access permissions to it.

That is enough to escalate. An attacker forces a privileged process such as Windows Defender to open the log file, and the authentication file gets created as SYSTEM. From the kernel driver’s point of view the request came from the antimalware engine’s own process, so it passes the check.

Naceri argues the same property defeats tamper protection on any security product: “it can be used against any antimalware engine to bypass their self defense (or tamper protection) mechanism, as you can trigger arbitrary file creation in the context of their own antimalware process so from the perspective of their kernel drivers, the file creation request is coming from their own legit process so it passes, this makes this vulnerability unique as it can be used to turn off any antivirus/EDR.” He frames it as Microsoft having implemented the mitigation properly, with the logic still allowing abuse.

Not every machine is exposed. Naceri tested SignDrop on Windows 11 26H2, Windows 11 26H2 Experimental, and Windows Server 2025 Experimental, and estimates 80% of Windows installations are vulnerable.

There are two ways to check. Run his proof-of-concept; if it spawns a SYSTEM shell, the machine is vulnerable. Or read HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication\Mode. A value of 0 (learning mode) or 1 (enforcement mode) means vulnerable.

There is no fix yet, and the obvious workaround makes things worse. Disabling the CLFS mitigation would reopen the memory-corruption attacks it was built to stop, so the only option Naceri offers is waiting for a patch from Microsoft.

The disclosure pattern matters here. Naceri, who says he is a former Microsoft employee, has published a long run of Windows zero-days since April: BigDiskBuster, ShieldCrash, ShieldBreak, LegacyHive, RoguePlanet, BlueHammer, RedSun, YellowKey, GreenPlasma, MiniPlasma, and UnDefend, mostly against Defender, BitLocker, and related components. Five years ago he released a set of privilege-escalation zero-days for various Windows versions. He discloses publicly without reporting privately first, and after one such round Microsoft warned of legal action against anyone engaged in “malicious activity causing real harm” to its customers, which much of the infosec community read as a threat aimed at him.

Microsoft has fixed some of these since the start of the year: ShieldBreak, RoguePlanet, YellowKey, GreenPlasma, and MiniPlasma. The rest, SignDrop included, still have no official fix.