Nightmare Eclipse publishes SignDrop Windows zero-day exploit abusing CLFS and Defender

Security researcher Abdelhamid Naceri, who goes by Nightmare Eclipse online, published a Windows zero-day exploit this week. He calls it SignDrop, and it lets a local user raise their privileges to System by abusing logic in the Windows Common Log File System (CLFS). SecurityWeek reported the release on 13 November 2026.

There's no CVE attached to it in the reporting, no patch, and no word from Microsoft. SecurityWeek says it emailed the company for a statement and would update if one came back.

What the exploit does

CLFS parses log files in kernel mode, which is why it has been a favourite target for years. Last year Microsoft added CLFS logfile authentication, which uses authentication codes to check that a log file hasn't been tampered with.

SignDrop goes after how clfs.sys creates the authentication file, named .cnpf, while a log file is being created. Per Naceri's description, the code that creates or opens the container and log files will always open the container once the original log file is open. If the container is empty, CLFS tries to sign it whether or not the signature file exists.

That gives a standard user a lever. They create a log file and point it at a container path of their choosing. Then they call the signature update RPC interface, which gets Windows Defender to open the file in the context of the antimalware engine. Defender follows the path in the container, and if the signature file isn't there, one gets created with System privileges.

SecurityWeek hasn't tested SignDrop. Its account of the proof-of-concept is that the code uses this to create a signature file wherever the attacker wants, reopens it, drops a payload in, and ends up with a System shell.

Reach and testing

Naceri says he tested it on Windows 11 26H2, Windows 11 26H2 Experimental, and Windows Server 2025 Experimental, and that it should work on 80% of the world's Windows installations. His rule of thumb, quoted in the article: "You're generally vulnerable if your Windows installation is older than 90 days."

Cyderes, a cybersecurity services provider, says it compiled and ran the PoC and found no evidence the zero-day has been exploited in the wild.

HackZoneLabs assessment

The interesting part of SignDrop isn't the CLFS bug. It's the second half. A local user can already do plenty on a box they're logged into; what they can't normally do is get a signed Microsoft component to write a file for them as System. Using Defender's signature update path as the writer turns a file-creation primitive into something that runs at the highest privilege on the machine. That's the trust boundary being crossed, and it's the part we'd expect Microsoft to look at hardest, since the fix could sit in either clfs.sys or in how Defender handles paths handed to it.

The "80% of installations" figure is Naceri's estimate, not a measured count, and the 90-day line is a heuristic about how quickly Microsoft's CLFS authentication work reached machines. We'd treat both as claims until someone publishes a version-by-version breakdown. The three builds he tested are a narrow sample, and the article doesn't say which builds he found not vulnerable.

We'd also note the disclosure style. Naceri has a record of publishing CLFS privilege-escalation PoCs, and this one arrives with working code and no vendor fix in hand. That raises the odds of copycat use, though privilege escalation still needs a foothold first, so the practical exposure is to environments where an attacker already has a low-privileged account or code execution. Cyderes finding no in-the-wild use is worth something, but it's a snapshot from the week of release.

What's unknown, and what to check

Microsoft hasn't said whether it considers this a vulnerability, whether a fix is in progress, or which builds are affected. Nobody has published an independent technical write-up that we've seen, and the affected-version boundary is Naceri's word alone.

For defenders, the useful checks follow from the mechanism. Watch for unexpected .cnpf files appearing outside normal CLFS locations, and for Defender processes touching log or container paths a user shouldn't control. If you can't patch something that doesn't have a patch yet, the lever here is local access: an account that can't create log files can't drive this. That's a mitigation, not a fix, and it doesn't help against an attacker who already has a standard user shell.