Protection mechanism failure in Windows Shell

CVE-2026-32202 is a Windows Shell protection failure where a crafted LNK can make Explorer resolve a remote UNC path while rendering folder contents, triggering an outbound SMB connection and automatic NTLM authentication. In practice, that means a user can leak a Net-NTLMv2 hash just by browsing to a folder containing the malicious shortcut, without needing full execution of attacker code. Affected builds span broad Windows client and server populations, including examples in NVD such as Windows 10 1607 < 10.0.14393.9060, Windows 10 1809 < 10.0.17763.8644, Windows 10 21H2 < 10.0.19044.7184, Windows 10 22H2 < 10.0.19045.7184, Windows 11 23H2 < 10.0.22631.6936, Windows 11 24H2 < 10.0.26100.8246, Windows Server 2016 < 10.0.14393.9060, Windows Server 2019 < 10.0.17763.8644, Windows Server 2022 < 10.0.20348.5020, Windows Server 2022 23H2 < 10.0.25398.2274, and Windows Server 2025 < 10.0.26100.32690.

Microsoft's 4.3 MEDIUM score is technically defensible if you grade only the first primitive: spoofing with confidentiality impact and required user interaction. In the field, that undershoots reality because the reachable population is enormous, the interaction threshold is low enough to behave like near-zero-click in Explorer, the stolen hash is immediately useful for relay or cracking, and CISA added it to KEV on 2026-04-28, confirming real exploitation. This is not a CRITICAL worm or straight-to-RCE event, but it is absolutely patch-priority Windows hygiene for enterprise fleets.

Why this verdict

• Up from vendor MEDIUM because KEV beats CVSS. Once CISA adds a Windows client/server bug to KEV, the scoring conversation changes from *could this be abused?* to *attackers are already using it*.
• Huge reachable population. This rides Windows Explorer behavior on ordinary endpoints and servers, not some niche role or rare optional feature; that keeps the baseline high.
• Near-zero-click user interaction. The CVSS UI:R tag is technically true, but browsing a folder is much weaker friction than opening a macro or authenticating to an admin panel.
• Impact compounds through NTLM ecosystems. The first-stage bug leaks a hash, but relay/crack paths can turn that into lateral movement and privilege gain in real enterprise networks.
• Not CRITICAL because the chain has real brakes. Delivery still matters, outbound SMB can be blocked, NTLM relay protections can kill follow-on abuse, and the primitive is not straight-to-code-execution.

Why not higher?

This is not a wormable service exploit, not pre-auth RCE against an exposed daemon, and not guaranteed domain compromise from a single packet. The attacker usually needs a file-delivery stage, the victim to hit the folder, outbound auth to succeed, and then a workable relay or cracking path. Those are meaningful friction points even in messy enterprises.

Why not lower?

Dropping this to MEDIUM or LOW would ignore the strongest empirical signal available: it is KEV-listed and actively exploited. Also, the combination of ubiquity, easy trigger conditions, and credential-abuse follow-on makes this far more operationally useful than the vendor's confidentiality-only CVSS framing suggests.

1. Block outbound SMB now — Deny TCP/445 and related outbound SMB/WebDAV paths from user workstations and general-purpose servers to untrusted networks immediately, within hours because active exploitation is confirmed. This directly cuts the authentication-coercion step that makes the bug valuable while patch rollout catches up.
2. Constrain NTLM and relay paths — Tighten NTLM usage, require SMB signing where feasible, and prioritize relay-resistant service configs immediately, within hours in exposed user tiers and admin enclaves. Even if a hash leaks, you want the follow-on abuse path to fail.
3. Hunt for Explorer-initiated auth — Use EDR, proxy, firewall, and Windows log telemetry to flag explorer.exe-adjacent outbound SMB or suspicious authentication to unusual hosts immediately, within hours while exploitation is active. This is one of the few detections with decent signal for attempted use.
4. Filter shortcut delivery — Block or quarantine suspicious LNK files and archives containing shortcuts at email, web, and collaboration ingress points immediately, within hours. Delivery is still a real prerequisite, so killing the file path buys time.

Run this on the target Windows host or through your endpoint management tool. Invoke as powershell -ExecutionPolicy Bypass -File .\Test-CVE-2026-32202.ps1; standard user rights are usually enough because it only reads OS version data, but remote collection via your EDR/RMM may need its normal agent privileges.

# Test-CVE-2026-32202.ps1

# Checks local Windows build against known fixed build thresholds for CVE-2026-32202.

# Outputs: VULNERABLE / PATCHED / UNKNOWN

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=ERROR


$ErrorActionPreference = 'Stop'

function Get-BuildNumber {
    param([string]$VersionString)
    if (-not $VersionString) { return $null }
    $parts = $VersionString.Split('.')
    if ($parts.Count -lt 4) { return $null }
    return [int]$parts[3]
}

try {
    $cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
    $productName   = [string]$cv.ProductName
    $displayVersion = [string]$cv.DisplayVersion
    $releaseId     = [string]$cv.ReleaseId
    $currentBuild  = [string]$cv.CurrentBuild
    $ubr           = [int]$cv.UBR
    $buildLabEx    = [string]$cv.BuildLabEx
    $currentVersion = "10.0.$currentBuild.$ubr"

    # Mapping of known minimum fixed builds from public references.

    # Keys are major build numbers.

    $fixedByMajorBuild = @{
        '14393' = 9060   # Windows 10 1607 / Server 2016

        '17763' = 8644   # Windows 10 1809 / Server 2019

        '19044' = 7184   # Windows 10 21H2

        '19045' = 7184   # Windows 10 22H2

        '20348' = 5020   # Windows Server 2022

        '22631' = 6936   # Windows 11 23H2

        '25398' = 2274   # Windows Server 2022 23H2

        '26100' = 8246   # Windows 11 24H2 (Server 2025 uses same major build but higher fixed UBR below)

        '26200' = 8246   # Windows 11 25H2

        '28000' = 1836   # Windows 11 26H1

    }

    Write-Host "ProductName: $productName"
    if ($displayVersion) { Write-Host "DisplayVersion: $displayVersion" }
    elseif ($releaseId) { Write-Host "ReleaseId: $releaseId" }
    Write-Host "CurrentVersion: $currentVersion"
    if ($buildLabEx) { Write-Host "BuildLabEx: $buildLabEx" }

    # Special handling for Server 2025, which shares major build 26100 but has a different fixed UBR threshold in public references.

    if ($productName -match 'Server 2025') {
        if ([int]$currentBuild -ne 26100) {
            Write-Host 'UNKNOWN - Product claims Server 2025 but build is unexpected.'
            exit 2
        }
        if ($ubr -ge 32690) {
            Write-Host 'PATCHED'
            exit 0
        } else {
            Write-Host 'VULNERABLE'
            exit 1
        }
    }

    # Server 2012 / 2012 R2 are present in affected CPE data, but the retrieved public corpus here did not expose a fixed build threshold.

    if ($productName -match 'Server 2012') {
        Write-Host 'UNKNOWN - Windows Server 2012/2012 R2 appears in affected data, but no fixed build threshold was available in the retrieved source set.'
        exit 2
    }

    if (-not $fixedByMajorBuild.ContainsKey($currentBuild)) {
        Write-Host 'UNKNOWN - This Windows build is not in the current script mapping.'
        exit 2
    }

    $requiredUbr = [int]$fixedByMajorBuild[$currentBuild]

    if ($ubr -ge $requiredUbr) {
        Write-Host 'PATCHED'
        exit 0
    } else {
        Write-Host 'VULNERABLE'
        exit 1
    }
}
catch {
    Write-Host ('ERROR - ' + $_.Exception.Message)
    exit 3
}

Sources

1. NVD CVE-2026-32202
2. Microsoft Security Update Guide advisory
3. Akamai root-cause analysis by Maor Dahan
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS overview
6. FIRST EPSS API documentation
7. Help Net Security coverage of active exploitation
8. UpGuard affected/fixed build summary