New Windows SignDrop Zero-Day Elevates Local Users to SYSTEM via CLFS Driver
A new unpatched local privilege escalation zero-day vulnerability called SignDrop has been disclosed by researcher MSNightmare (aka Chaotic Eclipse). The exploit abuses the Common Log File System (CLFS) driver (clfs.sys) on Windows to escalate an attacker from standard user to NT AUTHORITY\SYSTEM by manipulating authentication files created by CLFS logs. The exploit coerces Microsoft Defender to create an authentication file with SYSTEM privileges, inheriting attacker-controlled permissions, enabling a SYSTEM shell. It also potentially bypasses antivirus and EDR tamper protections by masquerading file creation as a trusted security engine’s action. The vulnerability affects Windows 11 26H2 and Windows Server 2025 builds, with an estimated 80% of Windows installations exposed unless specific registry settings disable CLFS authentication enforcement. As this is a local exploit, initial code execution is required, making it suitable as a second-stage privilege escalation after phishing or malware. No CVE or patch has been released yet, and Microsoft has not confirmed the issue or reported in-the-wild exploitation. Defenders are advised to enforce least privilege, monitor unexpected ".cnpf" file creations by Defender, watch for ERROR_LOG_METADATA_CORRUPT errors, and avoid disabling existing CLFS mitigations to prevent re-exposure to other bugs. Previous CLFS flaws and mitigations offer detection guidance until an official fix is available.
Entenda a falha
A vulnerabilidade
SignDrop is an unpatched local privilege escalation zero-day in the Common Log File System driver (clfs.sys) on Windows. It has no CVE yet. An attacker who already runs code as a standard user can get a NT AUTHORITY\SYSTEM shell. The researcher also says it could bypass antivirus and EDR tamper protection. The exploit was tested on Windows 11 26H2 and Windows Server 2025. Systems are exposed when the CLFS authentication mode registry value is 0 (enforced) or 1 (learning), and not when it is 2 or 3. The researcher estimates 80% of installations are exposed, but that is an estimate and not a measured count. There is no patch, and Microsoft has not confirmed the issue.
Como funciona
When a CLFS log is created, the driver writes a ".cnpf" authentication file next to it. This file carries an HMAC that CLFS checks before opening logs, a mitigation Microsoft added after CVE-2025-29824. The attacker attaches extra containers to the log with the AddLogContainer API, and the driver always opens these associated containers together with the log. If an associated container is empty, CLFS signs it whether or not a signature file already exists. Normally this is harmless, because file creation uses the caller's own context. It goes wrong when a privileged process opens the log. The researcher coerces Microsoft Defender into opening it through the ServerMpUpdateEngineSignature call and redirects the path with object manager symbolic links. CLFS then creates the missing authentication file as SYSTEM, and the file inherits the original file's DACL, which the attacker controls.
Por que é vulnerável
The root cause is a logic flaw in the new CLFS authentication safeguard. For an empty associated container, CLFS signs it regardless of whether a signature file exists. This relies on the assumption that the opener is always the attacker's own process. That assumption breaks when a privileged process such as Defender is made to open the log through redirected paths. The file is then created with SYSTEM privileges but inherits attacker-controlled permissions. The articles do not describe a fix, since none exists yet. Disabling the mitigation is not a valid workaround, because it re-exposes the memory-corruption bugs it was built to stop.
Onde está
The articles name the clfs.sys driver, the AddLogContainer API, the ServerMpUpdateEngineSignature call and the registry key HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication\Mode; they name no function or commit.
Como foi descoberta
The flaw was disclosed by the researcher MSNightmare, also known as Chaotic Eclipse, who published a working proof of concept on GitHub on November 10, the same day as Microsoft's monthly updates. The articles do not say how the researcher found it or whether Microsoft was notified beforehand. As of November 11 there was no CVE, advisory or patch, Microsoft had not confirmed the claims, and no in-the-wild exploitation had been reported.
PoC pública
The researcher published a working proof of concept on GitHub on November 10. It chains the CLFS signing behavior with a coerced Defender call and symbolic link redirection to turn a standard user into SYSTEM, and it was tested on Windows 11 26H2 and Windows Server 2025. It is a working exploit, public before any patch exists, so anyone with local code execution could reuse it. Urgency is high for systems whose CLFS authentication mode is 0 or 1. Until a fix ships, rely on least privilege and on monitoring.
Explicação gerada por IA a partir da matéria e dos artigos, em 12/11/2026 05:16.
Linha do tempo
-
New Windows SignDrop Zero-Day Elevates Local Users to SYSTEM via CLFS Driver
ler a análise desta fonte ocultar
A new unpatched local privilege escalation zero-day vulnerability called SignDrop has been disclosed by researcher MSNightmare (aka Chaotic Eclipse). The exploit abuses the Common Log File System (CLFS) driver (clfs.sys) on Windows to escalate an attacker from standard user to NT AUTHORITY\SYSTEM by manipulating authentication files created by CLFS logs. The exploit coerces Microsoft Defender to create an authentication file with SYSTEM privileges, inheriting attacker-controlled permissions, enabling a SYSTEM shell. It also potentially bypasses antivirus and EDR tamper protections by masquerading file creation as a trusted security engine’s action. The vulnerability affects Windows 11 26H2 and Windows Server 2025 builds, with an estimated 80% of Windows installations exposed unless specific registry settings disable CLFS authentication enforcement. As this is a local exploit, initial code execution is required, making it suitable as a second-stage privilege escalation after phishing or malware. No CVE or patch has been released yet, and Microsoft has not confirmed the issue or reported in-the-wild exploitation. Defenders are advised to enforce least privilege, monitor unexpected ".cnpf" file creations by Defender, watch for ERROR_LOG_METADATA_CORRUPT errors, and avoid disabling existing CLFS mitigations to prevent re-exposure to other bugs. Previous CLFS flaws and mitigations offer detection guidance until an official fix is available.