Glass Houses: Shattering KASLR via Windows DWM (CVE-2026-20805)

In the modern exploit development landscape, memory corruption is only half the battle. You might have a perfectly good buffer overflow or a Use-After-Free (UAF), but if you don't know where you are in memory, you are firing blind. This is thanks to Kernel Address Space Layout Randomization (KASLR), which shuffles the kernel's furniture every time the system boots. To win, an attacker first needs a map. Enter CVE-2026-20805.

This vulnerability resides in the Desktop Window Manager (dwm.exe), the process responsible for the pretty visual effects, window composition, and transparency in Windows. Because DWM needs to talk to practically everything on the screen, it holds a massive number of handles to system objects. It sits at a privileged intersection between user-land and kernel-land.

Security researchers discovered that dwm.exe is a bit of a blabbermouth. When asked politely via specific Windows Native APIs, it inadvertently hands over the raw 64-bit virtual addresses of its kernel objects. For an attacker, this is like finding the blueprints to the bank vault taped to the front door. It transforms a 'guess-and-pray' exploit attempt into a calculated, deterministic strike.

The root cause of this vulnerability is a failure to sanitize kernel metadata before returning it to user mode. The Windows kernel tracks resources using 'Objects' (Files, Processes, Threads, etc.), and user-mode applications reference these via 'Handles'.

When a process calls NtQuerySystemInformation with the SystemExtendedHandleInformation class, the kernel generates a list of all open handles on the system. Historically, Microsoft has hardened this API. For standard users, the Object pointer field (which contains the actual kernel memory address) is supposed to be redacted—usually zeroed out or obfuscated—to prevent exactly this kind of mapping.

However, the logic handling Asynchronous Local Procedure Call (ALPC) ports and Section Objects within the context of dwm.exe missed a spot. The specific structures initialized for DWM's ALPC communication channels fail to apply the necessary mask when enumerated. This means that when the handle table is traversed, the kernel says, 'Here is the handle ID, and oh, here is the exact 64-bit memory address where the ALPC port object lives in the kernel pool.'

[!NOTE] Technical Nuance: This isn't a corruption bug. The code works exactly as written; it just shares too much. It is a logic error in the boundary between SystemExtendedHandleInformation reporting and the specific object type attributes of DWM's resources.

To understand the gravity of the situation, we have to look at how an attacker views the system. They aren't looking at source code; they are looking at structures returned by the Windows Native API. The critical structure involved is SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX.

Below is a reconstruction of the data leak. A secure implementation (Before the exploit is known) assumes the kernel sanitizes the pointer. The vulnerable reality allows the Object field to pass through untouched.

The Vulnerable Structure View

// Definition of the handle information structure
typedef struct _SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX {
    PVOID Object;                // <--- THE LEAK. Should be NULL/Obfuscated for low-priv users.
    ULONG_PTR UniqueProcessId;   // We look for DWM's PID here
    ULONG_PTR HandleValue;
    ULONG GrantedAccess;
    USHORT CreatorBackTraceIndex;
    USHORT ObjectTypeIndex;      // We look for ALPC Port (24/25) or Section (36)
    ULONG HandleAttributes;
    ULONG Reserved;
} SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX, *PSYSTEM_HANDLE_TABLE_ENTRY_INFO_EX;

The Logic Failure

In a simplified pseudo-code representation of the kernel's handle enumeration routine, the failure looks something like this:

// Pseudo-code of the kernel logic handling the query
foreach (Handle in SystemHandles) {
    Entry.UniqueProcessId = Handle.OwnerPid;
    Entry.HandleValue = Handle.Value;
    
    // Security Check: Should we hide the kernel address?
    if (RequesterMode == UserMode && !HasDebugPrivilege) {
        // The Fix would ensure ALL object types are scrubbed here.
        // The Bug: Specific ALPC objects owned by DWM bypass this or
        // are incorrectly classified, leaking the raw pointer.
        Entry.Object = NULL; // Expected behavior
    } else {
        Entry.Object = Handle.KernelObjectAddress; // Vulnerable path taken
    }
    
    CopyToUserBuffer(UserBuffer, &Entry);
}

Because of the oversight in CVE-2026-20805, the Entry.Object is populated with a value like 0xFFFFD58F80C0E5E0. Since the attacker knows the offset of the ALPC Port object relative to the Kernel Base (or can use the object to fingerprint the heap), KASLR is defeated.

Exploiting this vulnerability is trivial for any code running on the machine, even with low privileges. The attack does not require a race condition or complex heap grooming. It is a deterministic read.

The Attack Chain

1. Reconnaissance: The exploit first finds the Process ID (PID) of dwm.exe. This is standard behavior for any tool.
2. The Ask: The exploit allocates a large buffer and calls NtQuerySystemInformation with the SystemExtendedHandleInformation (64) class.
3. The Sift: The exploit iterates through the millions of handles returned. It filters for UniqueProcessId == DWM_PID.
4. The Gold: Inside the DWM handles, it looks for ObjectTypeIndex corresponding to ALPC Ports (typically index 24 on modern Windows versions, though this varies slightly by build).
5. The Calculation: It extracts the Object pointer. By subtracting known offsets for the specific Windows version (which can be determined dynamically), the attacker calculates the ntoskrnl.exe base address.

Exploit Flow Diagram

Once the KASLR slide is known, the attacker can adjust their ROP (Return Oriented Programming) gadgets in a secondary exploit (e.g., a vulnerable driver or another kernel bug) to achieve reliable code execution.

You might ask, 'So what? It's just an address.' In the world of high-tier exploitation, an information leak is often more valuable than a crash. A crash denies service; a leak enables control.

This vulnerability carries a CVSS score of 5.5, which feels deceptively low. However, its inclusion in the CISA Known Exploited Vulnerabilities (KEV) catalog tells the real story. Threat actors are using this right now.

The Force Multiplier

Many kernel vulnerabilities (like integer overflows or pool corruptions) are 'unreliable' because hitting the wrong memory address causes a Blue Screen of Death (BSOD), killing the attack and alerting defenders. By using CVE-2026-20805 to peek at the memory layout first, attackers turn 10% reliability exploits into 100% reliability weapons.

This vulnerability is particularly dangerous because it affects all modern versions of Windows, from Windows 10 up to Server 2025. It serves as the skeleton key for ransomware operators looking to escalate from a compromised user account to full NT AUTHORITY\SYSTEM control.

The remediation is straightforward but requires a system restart. Microsoft has patched the kernel logic to ensure that queries targeting DWM handles properly sanitize the Object field, regardless of the object type.

Mitigation Steps

1. Patch Management: Apply the January 2026 Cumulative Update immediately.
   • Windows 11 23H2: Update to build 10.0.22631.6491 or higher.
   • Windows Server 2025: Update to build 10.0.26100.7623 or higher.
2. EDR Telemetry: If patching is delayed, security teams should configure EDR solutions to flag high-volume calls to NtQuerySystemInformation originating from non-administrative processes. While legitimate software uses this API, repeated calls followed by memory probing are indicative of an exploit attempt.
3. Attack Surface Reduction: Where possible, restrict access to the machine. Since this is a local exploit, the attacker must already have code execution on the box. Preventing the initial foothold (phishing, drive-by downloads) remains the best defense against the start of this chain.