Microsoft Windows VBS Enclave untrusted pointer dereference enables local privilege escalation

Untrusted pointer dereference in Windows Virtualization-Based Security (VBS) Enclave allows an authorized attacker to elevate privileges locally.

• Windows 11 version 23H2: the record marks 10.0.22631.0 as the affected version and defines the boundary as less than 10.0.22631.7582. This branch appears twice in the data with identical boundaries.
• Windows 11 Version 24H2: the record marks 10.0.26100.0 as the affected version and defines the boundary as less than 10.0.26100.9445.
• Windows 11 Version 25H2: the record marks 10.0.26200.0 as the affected version and defines the boundary as less than 10.0.26200.9445.
• Windows 11 version 26H1: the record marks 10.0.28000.0 as the affected version and defines the boundary as less than 10.0.28000.2954.
• Windows Server 2025: the record marks 10.0.26100.0 as the affected version and defines the boundary as less than 10.0.26100.33438.
• Windows Server 2025 (Server Core installation): the record marks 10.0.26100.0 as the affected version and defines the boundary as less than 10.0.26100.33438.

Products, versions, or branches not listed in the record should not be inferred to be affected or unaffected.

Microsoft Windows Virtualization-Based Security (VBS) Enclave contains an untrusted pointer dereference flaw in which an untrusted pointer is dereferenced by the affected component. An attacker needs local access and low privileges; the recorded attack does not require user interaction and has low complexity. Successful exploitation could result in privilege escalation within the same security scope. The record does not identify the pointer source, code path, triggering interface, or detailed configuration prerequisite, so the exact input construction and exploit sequence remain unknown.

The record describes local exploitation by an authorized attacker with low privileges. The recorded attack complexity is low and no user interaction is required. The supplied record sets public_exploit to false and leaves known_exploited unset. No specific exploit, campaign, victim, or breach is identified in the available evidence; this does not prove that exploitation cannot occur outside the evidence reviewed.

Successful exploitation could provide local privilege escalation without changing the security scope described in the record. The potential technical impact includes loss of confidentiality, integrity, and availability on the affected system. Organizationally, an initially low-privilege local account or process could gain enough access to reach or modify protected resources, depending on the privileges obtained. The vulnerability is not described as remotely reachable, and the available evidence does not confirm security-boundary crossing or a specific compromise scenario.

Successful exploitation could turn low-privilege local access into higher privileges on the same system. Depending on the privileges obtained, this may increase the risk of accessing protected data, changing system configuration or software, and disrupting services. The issue deserves particular attention on servers and devices with multiple users or locally running processes that are not fully trusted. The record does not confirm a specific compromise, data loss, or service outage.

1. Apply the Microsoft security update for the exact product branch in use. The recorded boundaries are:

• Windows 11 version 23H2: 10.0.22631.7582.
• Windows 11 Version 24H2: 10.0.26100.9445.
• Windows 11 Version 25H2: 10.0.26200.9445.
• Windows 11 version 26H1: 10.0.28000.2954.
• Windows Server 2025: 10.0.26100.33438.
• Windows Server 2025 (Server Core installation): 10.0.26100.33438.

1. After servicing, verify that the installed build is no longer below the corresponding boundary for that branch. Do not use a fix for one branch to conclude that parallel branches are protected.
2. Prioritize servers, multi-user devices, and systems where low-privilege local accounts or processes are allowed to operate.
3. The record does not provide a specific workaround or configuration mitigation. If patching must be delayed, temporarily reducing unnecessary local accounts and processes is general risk management, not a vendor-confirmed mitigation.

1. Inventory Windows systems running the affected product branches and collect their actual operating system builds.
2. Compare each build with the corresponding boundary in affected_summary; do not use one branch's boundary to conclude that another branch is protected.
3. Distinguish the full Windows Server 2025 installation from Windows Server 2025 Server Core, because the record lists them separately.
4. Identify deployments that use or provide VBS Enclave through existing Windows inventory and administration tooling. The record does not name a specific configuration key, endpoint, or module for this check.
5. As a precaution, review unusual local privilege changes on systems whose patch status has not been verified. No specific log event or IOC is provided, and the absence of related telemetry does not prove that a system is safe.