A researcher has published working exploit code that takes a standard Windows user to SYSTEM by abusing the log-file signing check Microsoft added to the CLFS driver in October 2025. Microsoft has not confirmed the flaw, assigned a CVE or shipped a fix.

What happened

SignDrop, published on GitHub by Abdelhamid Naceri (MSNightmare) on 10 November, abuses how clfs.sys creates the .cnpf authentication file that accompanies a CLFS log. A standard user prepares a log and container under paths they control. When a privileged process such as Windows Defender later opens that log, the driver creates the missing authentication file in the privileged process's security context, and that file inherits the permissions of the original log.

Object manager symbolic links redirect the creation to a location the attacker chooses. The result is a SYSTEM-owned file the standard user can write to, which chains into a SYSTEM shell. Because the request appears to come from the antivirus engine's own process, kernel drivers accept it, so the same trick can be used to switch off tamper protection on antivirus and EDR products.

There is no CVE and no patch. Naceri tested on Windows 11 26H2 and a Windows Server 2025 preview build and estimates about 80 percent of Windows installations are exposed.

Who is affected

Exposure depends on the CLFS authentication mode, read at HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication\Mode.

• Mode 0 (enforced) or 1 (learning): inside the reported scope of the exploit.
• Devices that took Windows 11 25H2 or Windows Server 2025 updates from 28 October 2025 onward, where the feature enforces itself after the 90-day learning period.
• Mode 2 or 3 (disabled by an administrator, or by the system): outside the reported scope.

What to do now

Read the CLFS authentication mode on your Windows 11 and Server 2025 estate first, and treat the flaw as a post-exploitation step rather than a remote attack.

• Check the Authentication Mode value on a sample of endpoints and servers; 0 or 1 means exposed.
• Do not disable the CLFS mitigation to dodge the bug. That reopens the memory-corruption attacks the feature was built to block.
• Assume an attacker already has code execution to use this, so keep standard users off local admin and watch for SYSTEM-level child processes spawned by medium-integrity parents.
• Track MSRC for a CVE and a fix; earlier zero-days from the same researcher waited months for patches.

What this means for South African businesses

The flaw is not remotely exploitable, so it will not by itself breach a small business. Its value to an attacker is the last step: turning one stolen user account into full control of the machine and blinding the endpoint agent on the way. Most SME estates are a single phishing click away from that first foothold, which is what makes a public SYSTEM exploit with no patch worth tracking. Expect a fix in a monthly update at best, and plan around that.

Source: BleepingComputer.

Also on the blog

• Check Point CVE-2026-123039: gateways rooted, TSGA backdoor, ESXi wiper
• Microsoft 365 Copilot token theft: Luna Moth vishing beats MFA

Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.