Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2025-59033

CVE-2025-59033: Microsoft WDAC Privilege Escalation Flaw

CVE-2025-59033 is a privilege escalation vulnerability in Microsoft's Windows Defender Application Control that may allow vulnerable drivers to bypass blocklist protections. This article covers technical details, impact, and mitigation.

Published:

CVE-2025-59033 Overview

CVE-2025-59033 affects the Microsoft vulnerable driver block list, which is implemented as a Windows Defender Application Control (WDAC) policy. The policy correctly blocks entries specifying only the to-be-signed (TBS) portion of a code signer certificate. However, entries that pair a signing certificate TBS hash with a FileAttribRef qualifier such as file name or version may fail to block the targeted driver. The bypass applies whether or not hypervisor-protected code integrity (HVCI) is enabled. Microsoft disputes this CVE assignment and states that the driver blocklist is intended for use with HVCI.

Critical Impact

A local attacker with the ability to load a driver may bypass the vulnerable driver blocklist and execute a known-malicious signed driver, undermining a core Windows kernel-mode defense.

Affected Products

  • Microsoft Windows with Windows Defender Application Control (WDAC) driver block list
  • Windows systems relying on the Microsoft vulnerable driver block list for protection
  • Windows deployments with or without hypervisor-protected code integrity (HVCI) enabled

Discovery Timeline

  • 2025-09-08 - CVE-2025-59033 published to the National Vulnerability Database
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-59033

Vulnerability Analysis

The Microsoft vulnerable driver block list uses WDAC policy syntax to deny execution of known-malicious or exploitable kernel drivers. Each policy entry identifies a driver through certificate metadata, hashes, or file attributes. The vulnerability lies in how WDAC evaluates blocklist entries that combine a certificate TBS hash with a FileAttribRef qualifier. When both conditions are present, the enforcement logic may fail to match a targeted driver, allowing it to load. The issue maps to [CWE-420] (Unprotected Alternate Channel) and [CWE-693] (Protection Mechanism Failure).

The blocklist is a primary defense against bring-your-own-vulnerable-driver (BYOVD) attacks. A bypass restores utility to drivers that Microsoft explicitly enumerated as unsafe. Attackers frequently abuse such drivers to disable endpoint protection, tamper with kernel structures, or gain SYSTEM-level code execution.

Root Cause

The root cause is a policy-matching gap in WDAC enforcement. Blocklist entries that specify only the signer TBS hash apply broadly and correctly. Entries that add a FileAttribRef qualifier narrow the intended match to a specific file name or version, but the compound rule is not consistently enforced. As a result, drivers that should be denied by the composite rule can still load in kernel mode.

Attack Vector

Exploitation requires local access and the ability to install or load a kernel driver, which typically requires administrative privileges. An attacker stages a signed driver known to be on the vulnerable driver block list and loads it against a system where the enforcement gap applies. Because the bypass functions with or without HVCI, defenders cannot rely solely on virtualization-based protections to prevent the load. The vendor position is that the blocklist is intended to be paired with HVCI, and the disputed status reflects that scoping disagreement.

The vulnerability is described in prose because no verified proof-of-concept code is published. See the Microsoft Driver Block Rules documentation and the Jonny Johnson research post for additional technical context.

Detection Methods for CVE-2025-59033

Indicators of Compromise

  • Kernel driver load events (Windows Event ID 6 in the CodeIntegrity log) referencing drivers enumerated in the Microsoft recommended driver block list.
  • New or unexpected .sys files written to C:\Windows\System32\drivers\ or user-writable directories, followed by service creation.
  • Service creation events (Event ID 7045) that install kernel-mode services referencing signed but blocklisted drivers.

Detection Strategies

  • Enumerate the current WDAC-enforced driver block list on endpoints and compare loaded driver hashes against the Microsoft-published blocklist entries.
  • Alert on kernel driver loads whose signing certificate TBS matches a blocklisted signer, even when the file name or version differs from expected values.
  • Correlate driver installation events with subsequent tampering of security tooling, EDR service termination, or callback registration in the kernel.

Monitoring Recommendations

  • Forward Microsoft-Windows-CodeIntegrity/Operational and System event logs to a central data lake for retention and correlation.
  • Track changes to HKLM\SYSTEM\CurrentControlSet\Services for new kernel-mode driver services created outside patch or software deployment windows.
  • Continuously validate that HVCI and memory integrity remain enabled on managed endpoints, and alert when either is disabled.

How to Mitigate CVE-2025-59033

Immediate Actions Required

  • Enable hypervisor-protected code integrity (HVCI) on all supported systems, consistent with Microsoft guidance that the vulnerable driver block list is intended for use with HVCI.
  • Ensure the Microsoft vulnerable driver block list is enabled through Windows Security under Core Isolation, or via WDAC policy deployment.
  • Restrict local administrative privileges to reduce the population of users who can load kernel drivers.

Patch Information

Microsoft disputes the CVE assignment and has not released a dedicated patch. The vendor position is that the vulnerable driver block list is designed to be paired with HVCI, and that HVCI provides the enforcement guarantees the blocklist relies on. Administrators should follow the Microsoft Virtualization Protection Guide and keep the driver block list refreshed through Windows Update.

Workarounds

  • Deploy a custom WDAC policy that blocks drivers by hash in addition to TBS plus FileAttribRef combinations, removing reliance on the composite rule.
  • Enable Smart App Control and memory integrity to add additional kernel-mode load restrictions.
  • Use application control tooling to allowlist only drivers signed by trusted vendors required for business operations.
bash
# Verify HVCI and driver block list status on Windows
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | \
  Select-Object VirtualizationBasedSecurityStatus, \
                SecurityServicesConfigured, \
                SecurityServicesRunning, \
                CodeIntegrityPolicyEnforcementStatus

# Enable the Microsoft vulnerable driver blocklist via registry
reg add "HKLM\SYSTEM\CurrentControlSet\Control\CI\Config" /v VulnerableDriverBlocklistEnable /t REG_DWORD /d 1 /f

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.