A new proof-of-concept exploit nicknamed SignDrop is making the rounds in security circles, and it takes direct aim at one of Microsoft’s more recent defensive additions to Windows: the authentication layer bolted onto the Common Log File System (CLFS) to stop exactly this kind of attack. As of November 11, 2026, there’s no CVE identifier, no patch, and no confirmation from Microsoft — just a public GitHub repository and a researcher’s claims.

A Driver With a History of Trouble

CLFS is not a new source of headaches for Windows security teams. The kernel-mode driver, clfs.sys, has produced a long line of privilege-escalation bugs over the years because it parses complex, attacker-influenced log file structures deep inside the kernel. Get the parsing wrong, and a memory corruption bug becomes a ticket to SYSTEM-level access — the highest privilege tier on a Windows machine.

The pattern is serious enough that it has shown up in real ransomware intrusions. Earlier CLFS flaws, including one tracked as CVE-2025-29824, were reportedly exploited by a threat actor tracked as Storm-2460 in conjunction with the PipeMagic malware to deploy ransomware payloads. That history is exactly why Microsoft moved last year to harden the subsystem rather than just patch individual bugs as they surface.

How the HMAC Defense Was Supposed to Work

Starting with updates released on or after October 28, 2025, Windows 11 25H2 and Windows Server 2025 gained a new protection: every CLFS log file now carries a hash-based message authentication code (HMAC) built from the file’s contents and a secret key unique to that machine. If the code on a log file doesn’t check out, CLFS simply refuses to open it — in theory shutting the door on crafted, malicious log files altogether.

New installations roll into this protection gradually. Systems spend an initial 90-day “learning mode” period in which CLFS quietly back-fills authentication codes onto existing log files as it opens them. Only after that window closes does the driver switch over to full enforcement on its next startup.

What SignDrop Reportedly Does

A researcher using the handle MSNightmare (also known online as Nightmare Eclipse) posted the SignDrop proof-of-concept to GitHub on November 10, 2026. According to the researcher’s own write-up, the bug doesn’t attack the HMAC check directly — it goes after the moment a new CLFS log file is created and its companion “.cnpf” authentication file gets generated through the exposed \CLFS device.

The technique reportedly combines Windows object manager symbolic links with precise file-creation timing tricks. The researcher further claims the exploit can coax a high-privilege Windows Defender process into writing files into a location it shouldn’t, effectively using a trusted, elevated process as an unwitting accomplice.

The researcher’s own estimate — described as just that, an estimate rather than a measured figure — is that roughly 80% of Windows installations could be exposed, on the theory that machines in both the learning-mode and enforcement-mode states remain vulnerable to the technique described. That figure has not been independently verified.

Important Caveats Before You Panic

There are real limits on what SignDrop can do, even taking the claims at face value:

• It is strictly a local privilege-escalation exploit. An attacker needs to already be running code on the target machine as a standard user — it provides no way to break in remotely over a network by itself.
• No CVE has been assigned, Microsoft has issued no advisory, and no independent researcher appears to have reproduced or verified the claims publicly.
• There is no evidence of the technique being used in real-world attacks at this time.
• The researcher reports testing only against Windows 11 26H2 and Windows Server 2025 lab environments.
• By the researcher’s own account, the proof-of-concept does not function when CLFS authentication is disabled — which might sound like a workaround, but isn’t one worth pursuing.

Don’t Turn Off the Protection You’re Trying to Protect

It bears repeating because the temptation to “just disable the thing the exploit targets” is a natural but dangerous instinct: disabling CLFS authentication does not neutralize this risk, it reopens the door to the broader category of older CLFS attacks the feature was specifically built to close. Microsoft’s own documentation confirms the setting is enabled by default for good reason, and turning it off allows the driver to parse arbitrary, unauthenticated log files again — including deliberately corrupted ones.

What Defenders Should Actually Do

Until an official fix lands — most likely through a future Patch Tuesday cycle — security teams have a narrower, more practical set of options:

• Tighten control over which accounts can execute arbitrary code on sensitive or high-value machines, since the exploit requires existing code execution as a prerequisite.
• Monitor for unusual file-creation activity originating from Windows Defender or other elevated, trusted processes.
• Watch for unexpected CLFS-related error codes, such as ERROR_LOG_METADATA_CORRUPT, which could indicate exploitation attempts or failed attempts.
• Keep systems current on Windows updates and be ready to apply a fix promptly once Microsoft issues one.
• Leave CLFS authentication enabled regardless of this disclosure.

For now, SignDrop sits in an awkward but familiar category for defenders: a credible-looking, technically detailed claim from a researcher with a track record of public Windows exploit releases, unaccompanied by vendor confirmation or a patch. Treat it as a real possibility worth preparing for, not a confirmed crisis — but don’t dismiss it either, given how often CLFS has been a genuine attack vector in the past.