CVE-2026-26179 is a local privilege escalation vulnerability in the Microsoft Windows Secure Kernel caused by a double-free condition. The flaw stems from improper validation of an object's existence before additional free operations are performed on that object, creating a memory corruption condition in a highly privileged kernel component. On affected Windows systems, a successful attacker can exploit this bug to elevate privileges locally. Available reporting indicates the issue resides in the Secure Kernel and that successful exploitation may enable arbitrary code execution in the context of the VTL1 Secure Kernel.
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.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
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.
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.
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.
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.