Researcher discloses SignDrop zero-day for Windows SYSTEM access

Abdelhamid Naceri, known by the aliases Nightmare Eclipse and MSNightmare, publicly disclosed the SignDrop Windows zero-day on Nov. 10, 2026, posting exploit code and a detailed write-up on GitHub when Microsoft issued its November security updates. Naceri said the exploit redirects companion file creation through symbolic links, letting standard users reach a SYSTEM shell.

The Common Log File System, a Windows logging subsystem frequently targeted by attackers seeking local privilege escalation, appears in CISA’s catalog with 10 CLFS flaws exploited in attacks, including one linked to ransomware campaigns in April 2025. Microsoft added log-authentication mitigations to the driver in October 2025 updates covering Windows 11 25H2, 26H1 and Windows Server 2025. Naceri said exploitation of CLFS vulnerabilities dropped sharply following that mitigation, yet the mitigation itself introduced the new vulnerability.

The driver reads only log files it created, and beside each log sits a companion .cnpf file containing recovery data that carries the same security attributes as the original. The researcher’s published code shows a standard user building a CLFS log and container from paths the user controls; after a privileged process opens the log, the driver writes the .cnpf file using that process’s security context instead of the user’s. Naceri said CLFS applies access checks properly as it begins creating the authentication file, but another privileged process can abuse the logic if it opens the log file later.

SignDrop compels a privileged process, for example the Windows Defender antimalware service, to open a prepared log file, which leads the driver to generate a companion authentication file running with SYSTEM privileges. Attackers use object manager symbolic links, a Windows feature that redirects file operations, to send that file creation to a location chosen by the attacker, letting standard users seize control and obtain a SYSTEM shell. The published code designates the Defender antimalware service, activated through its update interface, as the privileged process.

Naceri characterized the flaw as able to bypass the self-defense or tamper protection of any antimalware engine because the file-creation request appears to originate from the engine’s own legitimate process. The repository claims the technique works against any antimalware engine running with elevated privileges, though that broader claim has not been tested.

Defender must be actively running for the exploit to succeed, and the published attack chain functions only when Defender is enabled. Launching the exploit causes every UAC prompt to open both a standard user shell and a SYSTEM shell while freezing other actions, making the activity visible to anyone at the machine.

Naceri ran the proof-of-concept against Windows 11 26H2, Windows 11 26H2 Experimental and Windows Server 2025 Experimental builds. Systems more than 90 days old generally move from learning to enforcement automatically, so established machines typically run the default setup the exploit targets. Systems are vulnerable when the CLFS authentication registry mode at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CLFS\Authentication\Mode is 0 or 1.

Approximately 80 percent of Windows installations are vulnerable, Naceri estimated, describing the figure as an estimate rather than an exact measurement. Independent verification came from Heewon Song of security firm 78researchlab’s PurpleHound offensive content team, who tested the exploit and confirmed that it functions, though he assessed it is not yet reliable enough for operational attacks. Sungyup Nam, head of research at 78researchlab, reported that assessment on Nov. 12, 2026.

Administrators can check exposure by reading the CLFS authentication mode under HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication; a Mode value of 0 or 1 lies inside the researcher’s claimed scope. The vendor’s mitigation guidance covers the setting and the risks of turning it off, since switching the registry value to 2 or 3 turns off the CLFS mitigation but allows CLFS to parse tampered log files and reopens the memory corruption flaws the protection exists to prevent. Naceri recommends running the proof-of-concept on a device to test it, and said a spawned SYSTEM shell shows the machine is vulnerable.

No confirmation, CVE identifier or security patch for the vulnerability had come from Microsoft as of Nov. 11 and 12, 2026, and no active SignDrop attacks have been reported. The November security updates contain no CVE identifier, advisory or patch for SignDrop, CISA’s Known Exploited Vulnerabilities catalog leaves it out, and no reported attacks rely on the exploit. Administrators currently lack any option besides waiting for Microsoft to issue a patch.

Naceri, a former Microsoft employee, released multiple Windows privilege-escalation zero-day exploits about five years ago and disclosed zero-days without first attempting private disclosure. Microsoft responded by warning of legal action against anyone whose malicious activity causes real harm to customers, and many in the infosec community saw the warning as a direct threat to the researcher. Microsoft has patched some of his earlier flaws, among them ShieldBreak, RoguePlanet, YellowKey, GreenPlasma and MiniPlasma, though zero-day bugs from his disclosures remain without an official patch.

Microsoft confirmed the earlier Defender exploit RoguePlanet as CVE-2026-50656 in June and issued a patch the next month, and the ShieldBreak bypass followed in August with CVE-2026-69414. Attackers have exploited three flaws from the researcher’s earlier Defender work.

SignDrop belongs to a different class of issue than the earlier exploits that targeted race conditions in Defender’s file handling, since it centers on the CLFS driver’s authentication feature itself, and the vendor’s security update guide is where to watch for a response. SignDrop is also purely local, meaning an attacker must already be able to run malicious code on the system before the privilege escalation can occur.

Everything is done properly by Microsoft here but the logic allows abuse

Abdelhamid Naceri, BleepingComputer