Windows Virtualization-Based Security

CVE-2026-83501 is an out-of-bounds read (CWE-125) in Windows Virtualization-Based Security (VBS) Enclave, the hypervisor-backed trusted execution environment that protects secrets like Credential Guard material, Windows Hello biometric data, and SQL Server Always Encrypted processing buffers. A local, authenticated attacker with low privileges can trigger the OOB read to disclose memory contents from the enclave boundary. Affected builds span Windows 10 22H2 (< 10.0.22631.7582), Windows 11 24H2 (< 10.0.26100.9445), Windows 11 25H2 (< 10.0.26200.9445), and Windows Server 2025 (< 10.0.28000.2954). Microsoft patched it in the September 8, 2026 Patch Tuesday cycle.

Microsoft assigned CVSS 5.5 MEDIUM, which tracks with reality. The vector is AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N — local access, low privilege, high confidentiality impact, zero integrity or availability impact. The C:H reflects that enclave memory may contain high-value secrets, but the local-only attack vector and lack of any code execution or scope change keep this squarely in MEDIUM territory. There is no evidence of in-the-wild exploitation, no public PoC, and no KEV listing. This is a *defense-in-depth erosion* bug, not a breach vector on its own.

Why this verdict

• Local-only, post-compromise prerequisite: AV:L means the attacker must already have a foothold on the specific target host. This is not an initial access vector — it's a privilege/information escalation step that compounds on a prior chain.
• Information disclosure only, no code execution: C:H/I:N/A:N means the attacker reads secrets but cannot write, execute, or disrupt. The scope is Unchanged (S:U), so impact is confined to the single host.
• No PoC, no exploitation, no KEV: Published yesterday with zero public exploit code. VBS enclave internals are complex and poorly documented for attackers, raising the practical bar above what the AC:L vector suggests.
• Role multiplier: VBS Enclave is deployed across enterprise Windows endpoints and servers. On workstations with Credential Guard, a successful read could leak cached NTLM hashes — blast radius is host-level, MEDIUM. On domain controllers with Credential Guard, leaked material could theoretically aid lateral movement, but the attacker already has local DC access which is itself a near-DA position — incremental value is marginal. On SQL servers with Always Encrypted enclaves, plaintext data exposure is bounded to that server's dataset. No role produces fleet-scale or supply-chain-scale impact from this info-disclosure alone. The floor remains MEDIUM because no high-value role outcome reaches domain/fleet compromise without chaining additional, separate vulnerabilities.
• VBS enablement is not universal: While Microsoft pushes VBS/HVCI on modern hardware, many older fleet hosts and servers lack it or have it disabled. The exploitable population is a subset of Windows hosts, not the full Windows installed base.

Why not higher?

Promoting to HIGH would require either remote exploitability, a demonstrated chain to code execution, active exploitation, or a plausible single-hop path to domain/fleet compromise. None of these conditions are met. The local-only vector means the attacker is already inside the host — the incremental risk of reading enclave memory is real but bounded. No public PoC exists, and the scope is unchanged.

Why not lower?

Dropping to LOW would undervalue the C:H rating — VBS enclaves are *specifically designed* to protect the most sensitive secrets on the host (Credential Guard material, biometric keys). An OOB read that pierces that boundary defeats a deliberate security isolation mechanism. Even without a public PoC today, the low complexity (AC:L) and low privilege (PR:L) requirements mean weaponization is plausible once researchers dig in. The defense-in-depth erosion is meaningful.

1. Prioritize patching VBS-enabled hosts — Use your vulnerability scanner or SCCM/Intune to identify hosts where VBS/Credential Guard is active and prioritize the September cumulative update for those. Hosts without VBS enabled are not exploitable. No mitigation SLA applies for MEDIUM — go straight to the 365-day noisgate remediation SLA.
2. Audit VBS/Credential Guard enablement status — Run Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard across fleet to understand your actual exposure. Hosts returning VirtualizationBasedSecurityStatus = 2 (running) are in scope.
3. Harden local logon access — Restrict interactive and RDP logon to domain controllers and sensitive servers using Group Policy (User Rights Assignment → 'Allow log on locally'). This reduces the pool of accounts that could trigger the local exploit on high-value hosts.
4. Monitor for anomalous enclave API usage — If your EDR supports it, create detection rules for unusual calls to CreateEnclave, LoadEnclaveData, or CallEnclave APIs from non-standard processes. This provides early warning if exploitation tooling emerges.

Run on each target Windows host as a standard user (no admin required). Execute: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-83501.ps1. The script checks whether VBS is active and whether the OS build is in the affected range.

#Requires -Version 5.1
<# Check-CVE-2026-83501.ps1
   Checks if the host is vulnerable to CVE-2026-83501
   (OOB Read in Windows VBS Enclave)
   Output: VULNERABLE / PATCHED / UNKNOWN
   Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN
#>

$ErrorActionPreference = 'Stop'

try {
    # Check VBS status
    $dg = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard -ErrorAction SilentlyContinue
    if (-not $dg -or $dg.VirtualizationBasedSecurityStatus -ne 2) {
        Write-Host "PATCHED - VBS is not running on this host; CVE-2026-83501 is not exploitable."
        exit 0
    }

    # Get OS build
    $build = [System.Environment]::OSVersion.Version
    $fullBuild = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR
    $major = $build.Build
    $patch = $fullBuild

    Write-Host "VBS is ACTIVE. OS Build: $major.$patch"

    # Affected ranges and their fixed UBR values
    $vulnerable = $false
    switch ($major) {
        22631 { if ($patch -lt 7582) { $vulnerable = $true } } # Win10 22H2
        26100 { if ($patch -lt 9445) { $vulnerable = $true } } # Win11 24H2
        26200 { if ($patch -lt 9445) { $vulnerable = $true } } # Win11 25H2
        28000 { if ($patch -lt 2954) { $vulnerable = $true } } # Server 2025
        default {
            Write-Host "UNKNOWN - Build $major is not in the known affected range. Verify manually."
            exit 2
        }
    }

    if ($vulnerable) {
        Write-Host "VULNERABLE - CVE-2026-83501: Build $major.$patch is below the fixed version. Apply September 2026 cumulative update."
        exit 1
    } else {
        Write-Host "PATCHED - Build $major.$patch is at or above the fixed version."
        exit 0
    }
} catch {
    Write-Host "UNKNOWN - Error during check: $_"
    exit 2
}

Sources

1. THREATINT CVE-2026-83501 Detail
2. Talos - Microsoft Patch Tuesday September 2026
3. CrowdStrike - September 2026 Patch Tuesday Analysis
4. CybersecurityNews - September 2026 Patch Tuesday
5. Microsoft Learn - VBS Enclaves Overview
6. Microsoft Security Blog - VBS Memory Enclaves
7. Tech-Insider - Patch Tuesday September 2026