Three days after November Patch Tuesday came and went without incident, a researcher published a working Windows zero-day on GitHub. The exploit, called SignDrop, escalates a standard user to SYSTEM in one chain — and it does it by abusing the security hardening Microsoft shipped last year to stop exactly this kind of attack. No CVE. No patch. Public proof of concept, right now.
What You Are Running On
SignDrop affects Windows 11 25H2 and 26H2, along with Windows Server 2025. The researcher behind it estimates approximately 80% of active Windows installations are in scope. The exploit requires the attacker to already have local code execution as a standard user — it does not get you in the front door. What it does is take that foothold and hand you the keys to the entire machine.
As of November 13, 2026, Microsoft has not assigned a CVE, has not issued an advisory, and has not commented publicly. The next scheduled Patch Tuesday is December 9. That is the realistic earliest window for a fix.
How Microsoft’s Own Hardening Became the Attack Surface
To understand SignDrop, you need a quick history of clfs.sys. The Windows Common Log File System driver accumulated five CVEs in 2025 alone — including CVE-2025-29824, which was actively exploited in ransomware campaigns before Microsoft patched it. The pattern was always some variant of heap corruption or use-after-free in the driver.
Microsoft’s response in October 2025 was CLFS log authentication: every CLFS log now gets a companion .cnpf signature file that lets clfs.sys verify the log’s integrity. The idea was sound. If attackers corrupt CLFS memory structures, the signing mechanism would detect it. Five CVEs patched, hardening shipped, done.
SignDrop turns that signing logic into a privilege escalation primitive.
Here is the chain at a non-kernel level: a standard user creates a CLFS log at an attacker-controlled path. Using Windows Object Manager symbolic links and an oplock timing trick, the exploit redirects path resolution so that when Windows Defender — MsMpEng.exe, running as SYSTEM — opens the log to validate it, clfs.sys creates the .cnpf authentication file at a path the attacker chose, with SYSTEM-level privileges. That privileged file creation becomes the primitive. A DLL gets planted at the resulting location, and the payload executes: conhost.exe spawns as SYSTEM, and the UAC consent dialog disappears.
No memory corruption. Pure logic. The exploit specifically depends on Defender being present — which it is, by default, on nearly every Windows machine.
The obvious question: can you disable the CLFS signing mitigation to close this off? Technically yes, but security researchers are uniformly against it. Turning off CLFS authentication re-exposes the machine to the memory corruption CVEs the feature was built to close. You would be trading a local privilege escalation with no current attacker usage for known primitives that ransomware groups have already weaponized.
Who Released It and Why It Keeps Happening
SignDrop is the ninth entry in what the security community tracks as the Nightmare Eclipse cluster. The researcher operates under several aliases — MSNightmare, Nightmare-Eclipse, Chaotic Eclipse — and has published sixteen Windows zero-days in seven months, every single one timed for release on or just after Patch Tuesday to maximize the gap before a fix can ship. Previous entries include BlueHammer, RedSun, UnDefend, GreenPlasma, and ShieldCrash. The researcher’s real identity is unknown; informed speculation points to a former Microsoft employee with a grievance.
No criminal attacks have been attributed to Nightmare Eclipse. This appears to be adversarial disclosure rather than active exploitation — but that distinction matters less once the PoC is on GitHub and threat actors can read.
What to Do Right Now
There is no patch. Here is what you can actually do until December:
- Restrict untrusted local execution. SignDrop requires code already running as a standard user. Tighten AppLocker or WDAC policies on shared machines, CI/CD runners, and terminal servers. If untrusted code cannot run, SignDrop cannot start.
- Monitor for CLFS activity in user-writable paths. Flag any
.cnpffile creation initiated by MsMpEng.exe or other security product processes outside expected Windows directories. Event ID 4663 is your starting point. - Keep EDR telemetry online. The evidence from this exploit chain exists in real-time file creation and process creation logs, not in files that survive a post-incident sweep. Retention matters.
- Prioritize shared environments. Terminal servers, Windows CI/CD runners, and cloud VMs where multiple users or pipelines share a machine are the highest-risk deployments.
Patch when Microsoft ships the fix. Watch December 9.
