A researcher published exploit code on Tuesday that claims a standard local Windows user can reach SYSTEM privileges through the Common Log File System driver. Microsoft has not confirmed the flaw, assigned a CVE, or released a fix.

The proof of concept is called SignDrop. The researcher publishes under the name MSNightmare, and released both the code and a detailed writeup on GitHub. The timing is not subtle. It went up the same day Microsoft shipped its November security updates.

What CLFS Is, and Why It Keeps Appearing in Exploits

CLFS is a logging subsystem built into Windows. Its driver, clfs.sys, has been a recurring target for privilege escalation research, and the reason is structural. It parses log files, log files are data, and data is where memory corruption lives.

Ten CLFS flaws appear in CISA's catalog of vulnerabilities known to have been exploited in attacks, including one used in ransomware campaigns in April 2025.

That history is why Microsoft added an authentication check to CLFS log files in October 2025, for Windows 11 25H2, 26H1, and Windows Server 2025. The check attaches a hash-based message authentication code built from the log data and a key unique to each machine. The driver then parses only the log files it wrote.

SignDrop does not break that check. That is what makes it interesting.

What SignDrop Actually Does

The researcher targets a feature rather than a bug. The flaw, as described, lives in how the driver creates companion files.

When CLFS handles an authenticated log, it also creates a .cnpf file that stores recovery data beside it. According to Microsoft's own logfile authentication page, that file is created with the same security attributes as the original log.

Here is the sequence in the proof of concept.

In the published code, the privileged process is the Defender antimalware service, triggered through its update interface.

The researcher's own summary is unusually honest about what this is. Everything is done properly by Microsoft here, but the logic allows abuse.

That distinction matters. This is not a parser bug or a memory corruption flaw. It is an abuse of a feature working as designed, in a context where the design assumption does not hold.

The Tested Scope

The repository states the exploit was tested on Windows 11 26H2, a Windows 11 26H2 Experimental build, and Windows Server 2025 Experimental.

The exposure condition is specific. Systems are affected when the CLFS authentication registry mode is set to 0 (enforced) or 1 (learning).

That second value is the one that matters practically. Systems older than 90 days typically move from learning to enforcement automatically, which means the default configuration on established installations is the one the exploit targets.

A registry value of 2 or 3 means the mitigation is disabled. That does take the system outside the claimed attack surface, but both the researcher and Microsoft's own documentation warn against it. Disabling CLFS authentication lets the driver parse tampered log files again, which reopens the memory corruption flaws the protection was built to prevent.

Independent Testing Says It Works, With Caveats

Sungyup Nam, head of research at Korean security firm 78researchlab, published an assessment today. Researcher Heewon Song, from the firm's PurpleHound offensive content team, tested the exploit and found that it works.

Song's assessment adds a second finding that changes how seriously to take the practical risk. It does not run reliably enough for operational use.

There are additional constraints.

• Defender must be enabled. The published chain depends on triggering the Defender update interface as the privileged process.
• The exploit is loud. Running it changes every UAC prompt to open a standard user shell and a SYSTEM shell. That blocks other actions and makes the attack visible to anyone sitting at the machine.

That is the difference between a reliable attack and a demonstration. An attacker who needs a user to be absent, and who leaves the machine's permission prompts broken in a visible way, has a narrow window.

The repository also claims the technique can work against any antimalware engine whose process runs with elevated privileges. That broader claim has not been tested.

The Patch Status

There is nothing to install for SignDrop.

No CVE, advisory, or patch appeared in the November security updates. CISA's Known Exploited Vulnerabilities catalog does not list it. No attacks using the exploit have been reported.

That is not reassurance. It is a status, and status changes. The earlier entries in this researcher's record show how quickly.

The Researcher's Track Record

This is not a first-time disclosure, and the pattern is worth understanding.

The researcher has released a series of exploits targeting Windows and Defender since April.

Three of the researcher's earlier Defender flaws have been exploited in attacks. Two more were confirmed and patched. That is a track record that argues for attention even when the current proof of concept is unreliable.

SignDrop is also a different class of issue from the earlier work. Where those targeted race conditions in Defender's file handling, this one targets the CLFS driver's own authentication feature. The attack surface moved.

How to Check Your Exposure

Administrators can read the CLFS authentication mode at:

HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication

A Mode value of 0 or 1 falls within the researcher's claimed scope.

Do not respond by setting it to 2 or 3. Microsoft's mitigation guidance describes both the setting and the risks of disabling it, and the risk is not theoretical. Turning off authentication restores the exact exposure the feature was built to eliminate, and that exposure has a documented history of ransomware use.

What Defenders Should Do

• Check the CLFS authentication mode on your fleet. Mode 0 or 1 is in scope. Mode 2 or 3 is out of scope but carries a larger risk.
• Do not disable CLFS authentication to avoid this. The trade is a loud, unreliable local privilege escalation for an open door to tampered log parsing, which is where the actual ransomware-linked flaws lived.
• Watch for UAC prompt behavior changes. The exploit breaks permission prompts so they open shells instead of consent dialogs. That is a visible, detectable symptom.
• Monitor Defender update interface activity that originates from unexpected local processes.
• Watch for object manager symbolic link creation in unexpected contexts. That is the redirection mechanism, and it is not a common operation.
• Treat local user accounts as a real boundary on Windows. This exploit requires local code execution first. A machine where a standard user can already run code is a machine where this becomes relevant.
• Track the researcher's disclosures. Three of the prior exploits in this series were used in attacks. That is the strongest available signal about what comes next.
• Watch Microsoft's security update guide. That is where a response will appear, and given the timing of this release, the next Patch Tuesday is the obvious checkpoint.

The Design Lesson

Microsoft built a defense, deployed it, and a researcher found that the defense's own file-handling created a new path.

That is not a failure of the authentication check. The check works. What SignDrop exploits is that creating a companion file in a privileged context, and letting it inherit permissions from a user-controlled original, produces a file with a mismatched trust level.

That kind of flaw is hard to find by fuzzing because nothing crashes. It is found by reading the design and asking what the permissions imply.

FAQ

What is SignDrop?

A public proof-of-concept exploit that claims a local Windows user can gain SYSTEM privileges by abusing how the CLFS driver creates .cnpf companion files for authenticated logs.

Has Microsoft confirmed the flaw?

No. Microsoft has not confirmed the claimed flaw, assigned a CVE, or released a fix.

How does the exploit work?

A standard user prepares a CLFS log with attacker-controlled paths. When a privileged process opens it, the driver creates the companion file in that privileged context. Object manager symbolic links redirect the creation, and because the file inherits the log's permissions, the standard user ends up with a SYSTEM-created file they can write to.

Which systems are affected?

The researcher tested Windows 11 26H2, a Windows 11 26H2 Experimental build, and Windows Server 2025 Experimental. Systems are in scope when the CLFS authentication registry mode is 0 (enforced) or 1 (learning).

What about mode 2 or 3?

Those values disable the mitigation, which takes the system outside the claimed attack surface. Both the researcher and Microsoft warn against it, because disabling authentication lets CLFS parse tampered log files again.

Does the exploit actually work?

Yes, according to 78researchlab, whose researcher Heewon Song tested it independently. But the firm assessed that it does not run reliably enough for operational use.

What are the practical constraints?

Defender must be enabled, because the chain triggers the Defender update interface as the privileged process. And the exploit visibly breaks UAC prompts, turning them into shells, which makes the attack obvious to anyone at the machine.

Is there a patch?

No. No CVE, advisory, or patch appeared in the November security updates, and the exploit is not in CISA's KEV catalog.

How do I check my exposure?

Read the CLFS authentication mode at HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication. A Mode value of 0 or 1 is in the claimed scope.

Is this researcher credible?

They have released a series of Windows and Defender exploits since April. Three of their earlier Defender flaws were exploited in attacks, RoguePlanet was confirmed as CVE-2026-50656 and patched, and ShieldBreak was assigned CVE-2026-69414.

Why does CLFS keep showing up in exploits?

It parses log files, which are attacker-influenceable data. Ten CLFS flaws appear in CISA's catalog of exploited vulnerabilities, including one used in ransomware campaigns in April 2025.

Source: The Hacker News