
Public SignDrop Exploit Claims SYSTEM Access Through Windows CLFS
A public exploit called SignDrop claims local privilege escalation to SYSTEM through Windows CLFS by redirecting creation of a companion.cnpf file. Independent testing found it works but unreliable and noticeable, while Microsoft has not confirmed a CVE or released a fix. It matters because CLFS is widely present in Windows and Defender, and the mitigation tradeoff affects enterprise patch and security decisions.
Researcher MSNightmare published a proof-of-concept exploit called SignDrop on GitHub Tuesday, the same day Microsoft issued November security updates. The code claims a standard Windows user can escalate to SYSTEM by abusing the Common Log File System driver. It prepares a CLFS log, then uses object manager symbolic links to redirect creation of a companion.cnpf recovery file when a privileged process opens the log. In the published chain, the privileged process is Microsoft Defender's antimalware service, triggered through its update interface. The exploit was tested on Windows 11 26H2 and Windows Server 2025 experimental builds.
Microsoft has not confirmed the claimed flaw, assigned a CVE, or released a fix, and the November updates did not include a SignDrop advisory. CISA's Known Exploited Vulnerabilities catalog also does not list it. The evidence trail is still public code and a writeup, not an official vulnerability record. CLFS is a Windows logging subsystem, and its driver has been repeatedly targeted for privilege escalation. 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.
SignDrop attacks a protection Microsoft added in October 2025 for Windows 11 25H2, 26H1 and Windows Server 2025. That protection adds a machine-keyed hash-based message authentication code to CLFS logs, so the driver parses only files it wrote. The exploit targets the companion.cnpf file created when a privileged process opens a prepared log. Systems are exposed when the CLFS authentication registry mode is 0, enforced, or 1, learning; older systems usually move to enforcement automatically. Modes 2 or 3 disable the mitigation but reopen tampered-log parsing.
Independent testing by 78researchlab found the exploit works but is not reliable enough for operational use, and it requires Defender to be enabled. The attack also changes every UAC prompt to open both a standard-user shell and a SYSTEM shell, making it noticeable at the machine. The repository claims the method can work against any antimalware engine whose process runs elevated, but that broader claim is untested. The stakes are local privilege escalation on Windows systems where the mitigation is active, with defenders facing a tradeoff between protection and disabling it.
Windows and Windows Server systems using CLFS with authentication enabled can be exposed to local users who chain the flaw into SYSTEM access. Defenders must weigh patching pressure against the risk of disabling a mitigation that prevents other CLFS memory-corruption issues.
Sources (1)
- [1]Original source(https://thehackernews.com/2026/11/new-signdrop-zero-day-exploit-turns.html)