Microsoft Windows Secure Kernel Double Free Local Privilege Escalation
CVE-2026-26179 is a double-free vulnerability in the Microsoft Windows Secure Kernel. According to the provided advisory context, the flaw results from improper validation of an object's existence before additional free operations are performed on that object. A local attacker who can trigger the vulnerable condition may corrupt memory in the Secure Kernel and, upon successful exploitation, execute arbitrary code in the context of the VTL1 Secure Kernel. The issue is tracked by ZDI as ZDI-26-276 / ZDI-CAN-28189 and was publicly disclosed on April 15, 2026.
Are you exposed to this one?
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
Impact, mitigation & remediation
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
Impact
What an attacker gets, and what they’ve been doing with it.
Mitigation
If you can’t patch tonight, do this now.
Remediation
Patch, then assume compromise.
Exploits
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a small standalone proof-of-concept exploit for CVE-2026-26179 (also referenced as ZDI-26-276), described by the author as a Secure Kernel bug. The repo contains 6 files total: a README, Visual Studio solution/project files, and one substantive source file, Solution/Driver.c. The project is configured as a Windows WDM kernel-mode driver using the WindowsKernelModeDriver10.0 toolset, with build targets for x64 and ARM64. The exploit logic is entirely in Driver.c. In DriverEntry, the code defines hardcoded kernel symbol addresses for nt!VslpTraceLog, nt!VslpLockPagesForTransfer, VslpEnterIumSecureMode, and nt!VslpUnlockPagesForTransfer. The README/comments make clear these addresses must be manually adjusted for the target system, likely by resolving symbols in a kernel debugger. The driver then loops 100 times, each iteration zeroing local buffers, calling VslpLockPagesForTransfer to populate transfer metadata, crafting a 256-byte input structure with MDL, PFN, TransferSize, and DataByteCount fields, and invoking VslpEnterIumSecureMode(2, 55, 0, pData) to enter the vulnerable Secure Kernel path. Afterward it conditionally unlocks transfer pages using VslpUnlockPagesForTransfer. There are no network capabilities, C2, remote targets, or external URLs used by the exploit code. The attack vector is purely local and requires the ability to build/load a kernel driver. There is also no weaponized payload beyond vulnerability triggering: no shellcode, privilege persistence, user creation, or command execution. As written, this is a crash/repro-style PoC intended to demonstrate or study the Secure Kernel vulnerability rather than provide a generalized exploitation chain. Notable fingerprintable observables are the internal kernel routine names and the example hardcoded kernel addresses embedded in Driver.c. These are environment-specific rather than universal IOCs, but they clearly indicate the exploit's dependency on undocumented VTL1/Secure Kernel interfaces. Overall, the repository's purpose is to provide a minimal reproducible local kernel-driver PoC for exercising a rare published Secure Kernel bug.
Affected products & vendors
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
Recent activity
1 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
The version that knows your environment.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.