SignDrop Windows zero-day README says only 2 of 4 CLFS Mode values are safe, both with the mitigation off

The README's safe list is the mitigation's off list: 2 of 4 Mode values (derived)

A README in a public GitHub repository named SignDrop says a Windows machine is not vulnerable when the CLFS authentication Mode registry value is 2 or 3, and vulnerable when it is 0 or 1. Microsoft's support page for the mitigation defines four values: 0 is enforced, 1 is learning mode, 2 is "An Administrator disabled the mitigation." and 3 is "The mitigation was disabled automatically by the system." So the README's safe list is 2 of the 4 defined values (derived count), and both are states in which Microsoft's mitigation is off. That is the sense of the README's own claim: it says the flaw is created by the mitigation, so only a machine without the mitigation is spared.

What this does not establish. The README is one researcher's account. The repository holds a public proof of concept with source code and binaries, and this site has not run, fetched, compiled or opened it and has tested no machine. No page read states a CVE number, a CVSS score, a Microsoft response, a patch date or exploitation in the wild. The researcher's motive is not stated. The README page was saved at about 17:33 UTC on 12 November 2026 and Microsoft's page was read at 17:38 UTC; every "not stated" below is as read by about 17:42 UTC that day, and any of them could change within the hour.

The repository page's own data gives its creation time as 19:20 UTC on 10 November 2026. BleepingComputer's report is stamped 11:04 at UTC minus five hours (16:04 UTC, derived) on 12 November, 44 hours 44 minutes later (derived). The page data says when the repository was created, not when the README was written or the exploit first circulated. As saved it showed 254 stars, 61 forks, 7 commits and an MIT licence.

What the README says, and how far this site goes into it

The README says the flaw is in the Common Log File System driver, clfs.sys, in how it handles creation of the authentication file with the extension .cnpf when a new log file is created. BleepingComputer's prose summary is the level of detail used here: access checks are enforced correctly at the start, but the logic can be abused if a different, privileged process later opens the log file. Such a process can be forced to do so, the authentication file is then created with that process's privileges, and CLFS gives it the original file's access permissions. The README's example names Windows Defender as the privileged process. It goes into call level detail that this site does not repeat: no API names, object paths or call sequences appear in this article, and none are needed to read the checks below.

The researcher's summary of the position is "Everything is done properly by Microsoft here but the logic allows abuse." The README adds that the technique works against any antimalware engine's self defence, which it also calls tamper protection, because the file creation request appears to come from the engine's own legitimate process. That last claim is reasoning in the README: it names no product other than Windows Defender and lists no tests of any other.

On scale the README says "I guess estimate 80% of the world's windows installations are vulnerable to this" and "it's safe to assume that everyone reading this is definitely vulnerable" Both are the researcher's estimates, and the README lists three tested builds: Windows 11 26H2, Windows 11 26H2 Experimental and Windows Server 2025 Experimental. The README does not say how 80% was reached and does not explain what Experimental means.

What Microsoft's page says about the mitigation

The Microsoft page (KB ID 5056852) calls it a "hardening authentication mitigation" that adds a hash based message authentication code to the files behind a CLFS log file, using a system unique key stored in the registry. It says the page's original publish date is 28 October 2025 and that the mitigation is in Windows 11 version 25H2 and Windows Server 2025 updates released on or after that date. Its applies to list names Windows 11 25H2, Windows 11 26H1 and Windows Server 2025.

A system receiving the update starts in learning mode, in which CLFS adds codes to log files that lack them. The adoption period lasts 90 days from the first start with the new CLFS, after which "the driver will automatically transition into enforcement mode on its next start" The page adds that the 90 day value may change. The registry Mode values map as 0 enforced, 1 learning, 2 an Administrator disabled it, 3 the system disabled it automatically. An Administrator can disable the mitigation by setting Mode to 2, and Microsoft says "we do not recommend it".

Zoom

Derived dates. 90 days after 28 October 2025 is 26 January 2026, and 12 November 2026 is 380 days after 28 October 2025. Any machine first started with the new CLFS before 14 August 2026 (90 days before the day of reading) is past the adoption period. The README's "older than 90 days" remark fits that. It follows, as inference and not as measurement, that a machine on a listed release which has run unchanged for more than 90 days should read Mode 0 on Microsoft's description, so the machines the README says are spared would be the ones where someone, or the system, turned the hardening off.

Do the README's two statements fit Microsoft's page?

Do the README's two statements agree? One says that a machine is vulnerable "in learning mode or enforcement mode", and the other that Mode 0 or 1 is vulnerable while 2 or 3 is not. On Microsoft's page they do. Mode 0 is enforcement and Mode 1 is learning, so both of the README's statements describe the same two values. The page does not settle whether the README's claim of vulnerability is true; it only settles the vocabulary.

BleepingComputer writes "0 or 1 (learning mode or enforcement mode)". Read in order, that pairs 0 with learning and 1 with enforcement, which is the reverse of Microsoft's page. The README itself does not pair them, so this is the secondary's phrasing, and the verdict for both is the same. A reader copying the parenthesis into a runbook would still invert the two.

Friendly labels doing the work of a control

Mitigation and hardening. Microsoft's page uses both words, and a label that reads as protective is not evidence about a property. The README's claim is that this control is itself the attack surface. One design fact is on Microsoft's page: "The patch file will be created with the same security attributes as the file it provides recovery information for." The README says CLFS "will always create the new authentication file with the original file DACL" and that this makes things worse. So a behaviour Microsoft documents as design is the one the README says is abused. Whether it is a flaw is the researcher's claim; no Microsoft statement on that is on any page read.

Learning mode. Microsoft's page says CLFS always opens log files in learning mode and writes codes to files that lack them. The README lists learning mode among the vulnerable states, so the label does not mean lower risk. Tamper protection and self defence. The README says a request made through an engine's own process passes the engine's kernel driver checks, because it comes from the engine itself. A control that trusts its own process is only as strong as what can steer that process, and the README gives no list of products tested. Experimental. Two of the three tested builds carry the word, and neither the README nor Microsoft's page defines it.

Where the sources differ

Eleven earlier names, and what is said about fixes

BleepingComputer's page lists eleven earlier zero-days from the same researcher: BigDiskBuster, ShieldCrash, ShieldBreak, LegacyHive, RoguePlanet, BlueHammer, RedSun, YellowKey, GreenPlasma, MiniPlasma, UnDefend. The count of eleven is this site's count of that list, and the list is BleepingComputer's. BleepingComputer says Microsoft has fixed some of them, naming ShieldBreak, RoguePlanet, YellowKey, GreenPlasma, MiniPlasma, which is 5 of 11 (derived), and says "the other zero-day bugs still lack an official patch". Subtracting gives 6 without an official patch on that account (derived): BigDiskBuster, ShieldCrash, LegacyHive, BlueHammer, RedSun, UnDefend. This site has not read Microsoft's update notes for any of the eleven. SignDrop would be a twelfth name on that list (derived). BleepingComputer names the researcher; this site names organisations, not individuals.

Microsoft's Security Response Center published a post dated 27 May 2026 about uncoordinated disclosure. It says of several recent zero-days "The details of these vulnerabilities were not shared with Microsoft prior to release", names six of the eleven as not responsibly disclosed (RedSun, UnDefend, BlueHammer, YellowKey, GreenPlasma and MiniPlasma), and calls uncoordinated disclosures that put proof of concept code for unpatched vulnerabilities into the hands of bad actors "never justifiable". The post predates SignDrop by 169 days (derived) and does not mention it. BleepingComputer, separately, quotes a Microsoft warning of legal action against "malicious activity causing real harm" and does not date it.

Interest, stated once. The README sells nothing and states no motive. Microsoft, whose code and mitigation are the subject and which would issue any patch, has an interest in coordinated disclosure that it states in that post. No Microsoft response to SignDrop is on the BleepingComputer page, and the README itself points readers with concerns about the repository to Microsoft's security mailbox.

What the README states, and what it does not

Zoom

What to do, in order

Technical details

The primaries print a registry key, four Mode values, an extension and a handful of settings. They print no hashes, domains, addresses or detection rules. The repository lists source files, project files and a library file; none was opened and no names are reproduced here. Each block below is copied from the page named in its caption. The only text this site wrote is the last block, marked derived.

Microsoft's registry key and value descriptions. Where the mitigation keeps its state, and what each Mode means. A defender reads Mode, and the two timing values beside it, and records them per machine. The Key value is the cryptographic key and should be left alone.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication
Mode : The operating mode of the mitigation
0 : The mitigation is enforced. CLFS will fail to open logfiles that have missing or invalid authentication codes. After 90 days of running the system with this version of the driver, CLFS will automatically transition into enforcement mode.
1 : The mitigation is in learning mode. CLFS will always open logfiles. If a logfile is missing authentication codes, then CLFS will generate and write the codes to the file (assuming caller has Write access).
2 : An Administrator disabled the mitigation.
3 : The mitigation was disabled automatically by the system.
EnforcementTransitionPeriod : The amount of time, in seconds, that the system will spend in the adoption period.
LearningModeStartTime : The timestamp at which learning mode started on the system.
Key : The cryptographic key used to create authentication codes (HMACs). Administrators should not modify this value.

The README's statements, copied exactly. These are the statements the checks above rest on: the flaw location and file extension, the registry value, the verdicts by Mode, the tested builds and the researcher's line on fixes.

The specific flaw exist in clfs.sys in the way how it handle the creation of the authentication file ".cnpf"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication\Mode
If it's set to 0 or 1 then you're vulnerable. If it's set to 2 or 3 then you're not vulnerable.
The vulnerability has been tested in windows 11 26H2, Windows 11 26H2 Experimental, Windows Server 2025 Experimental
so for now there is no solution to this except waiting for a patch to be released by Microsoft

Where the mitigation is switched on or off by policy. Microsoft's page names a Group Policy setting and an Intune custom setting, and gives an example of where a patch file sits next to its log file. A defender looks for any estate policy that has set the mitigation to disabled.

Enable / disable CLFS logfile authentication
If Not Configured is selected, the mitigation is enabled by default.
./Vendor/MSFT/Policy/Config/FileSystem/ClfsAuthenticationChecking
example.blf.cnpf

A read-only check, derived. These two lines were written by this site from the key and value names above. They read values and change nothing. They were not run on any machine for this article. Microsoft's page also prints a command that sets Mode to 2; it is not reproduced here because it switches the mitigation off.

reg query "HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication" /v Mode
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CLFS\Authentication" -Name Mode, EnforcementTransitionPeriod, LearningModeStartTime

The question the README leaves open

If the only machines the README calls safe are the ones with Microsoft's hardening switched off, which risk is an estate meant to hold while it waits for a patch, and who has decided it? No page read says what Microsoft will do, and the README itself says the alternative is memory corruption bugs. Until a Microsoft statement or a patch note appears, the registry value tells an administrator which side of that trade each machine sits on.

Key facts