Improper handling of insufficient permissions or privileges in Windows Installer

CVE-2026-27910 is a local elevation-of-privilege flaw in Windows Installer. Microsoft/NVD describe it as improper handling of insufficient permissions or privileges that lets an authorized local attacker elevate privileges on the same host. The affected set spans a broad slice of supported Windows releases published on April 14, 2026, including Windows Server 2012/2012 R2/2016/2019/2022/2025 and Windows 10 1607/1809/21H2/22H2 plus Windows 11 23H2/24H2/25H2/26H1; NVD lists affected builds as versions before the April 2026 cumulative-update build thresholds.

Microsoft's 7.8/HIGH CVSS is technically fair in a vacuum because successful exploitation can end in full local compromise, but it overstates operational urgency for most enterprises. The decisive friction is attacker position: this bug is not remotely reachable, not internet-exposed, and already assumes code execution or an authenticated local foothold on the target. With no KEV listing, very low EPSS (0.00052), and no public exploit trail surfaced in the reviewed sources, this behaves more like a post-initial-access privilege escalator than a front-door incident generator.

Why this verdict

• Start from 7.8/HIGH because a successful exploit can plausibly end in full local compromise with SYSTEM-level consequences on the host.
• Downshift for attacker position: AV:L + PR:L means the attacker already has code execution or an authenticated user session. In enterprise terms, that implies *post-initial-access*, not a new initial access path.
• Downshift for exposure population: there is no direct internet-facing surface to scan, weaponize at scale, or opportunistically hit. Shodan/Censys-style population pressure is effectively absent.
• Downshift for threat intel: no KEV, no confirmed in-the-wild exploitation, and very low EPSS (0.00052) materially reduce urgency versus truly active Windows zero-days.
• Hold above LOW because Windows Installer is ubiquitous and shared-user endpoints, jump boxes, RDS/VDI, and developer workstations give local EoP bugs real chaining value once an attacker lands.

Why not higher?

There is no unauthenticated remote path, no network reachability, and no evidence in the reviewed sources that attackers are actively burning this bug at scale. A HIGH or CRITICAL call would overreact to the impact while ignoring the much more important reality that the attacker must already be on the host.

Why not lower?

This still buys meaningful privilege expansion on one of the most common enterprise platforms in the world. If you have lots of shared-user Windows endpoints or any environment where low-priv execution is common after phishing or lateral movement, local EoP bugs remain useful chain components and should not be shrugged off as mere paperwork.

1. Prioritize shared-user Windows tiers — Move VDI, RDS, jump hosts, kiosks, help-desk workstations, and developer endpoints to the front of your normal patch queue because those are the systems where low-privileged user execution is common and this class of LPE has the most value. For a MEDIUM verdict there is no noisgate mitigation SLA, so use this as risk-based triage while you work through the standard remediation window.
2. Tighten application control around installer execution — Use WDAC/AppLocker to restrict who can launch untrusted msiexec flows, MSI packages, and common post-exploitation payload locations. This does not remove the vulnerability, but it raises friction on the likely exploit delivery stage while you remediate; for MEDIUM, there is no mitigation SLA.
3. Hunt for suspicious msiexec.exe behavior — Create EDR analytics for msiexec.exe spawning unusual child processes, touching temp paths at odd cadence, or correlating with privilege jumps and service/task creation. That won't stop exploitation deterministically, but it improves your odds of catching the chain early; again, no mitigation SLA applies at MEDIUM.
4. Reduce low-priv logon where it is unnecessary — On servers especially, remove casual interactive access for standard users and tighten who can log on locally or via RDP. The cleanest risk reduction here is simply shrinking the number of places where an attacker can satisfy the AV:L/PR:L prerequisite before you complete remediation.

Run this on the target Windows host or through your endpoint management tooling as a standard user; admin rights are not required for the registry reads used here. Example: powershell -ExecutionPolicy Bypass -File .\check-cve-2026-27910.ps1. The script compares the host's Windows build/UBR against the April 14, 2026 fixed build floors and prints VULNERABLE, PATCHED, or UNKNOWN.

# check-cve-2026-27910.ps1

# Purpose: Determine likely exposure to CVE-2026-27910 using Windows build/UBR thresholds.

# Output: VULNERABLE / PATCHED / UNKNOWN

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


$ErrorActionPreference = 'Stop'

try {
    $cvPath = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
    $cv = Get-ItemProperty -Path $cvPath

    $productName = [string]$cv.ProductName
    $displayVersion = [string]$cv.DisplayVersion
    $currentBuild = [int]$cv.CurrentBuildNumber
    $ubr = [int]$cv.UBR
    $versionString = "$currentBuild.$ubr"

    # Fixed build floors gathered from NVD/MSRC/CVE records for the April 14, 2026 patch train.

    # Some server entries beyond the NVD snippet are inferred from same-day Microsoft cumulative update lines.

    $fixed = @{
        9200  = 26026   # Windows Server 2012 (inferred from same patch train / sibling CVE records)

        9600  = 23132   # Windows Server 2012 R2 (inferred from same patch train / sibling CVE records)

        14393 = 9060    # Windows 10 1607 / Windows Server 2016

        17763 = 8644    # Windows 10 1809 / Windows Server 2019

        19044 = 7184    # Windows 10 21H2

        19045 = 7184    # Windows 10 22H2

        20348 = 5020    # Windows Server 2022 (inferred from same patch train / sibling CVE records)

        22631 = 6936    # Windows 11 23H2

        25398 = 2274    # Windows Server, version 23H2 (inferred from same patch train / sibling CVE records)

        26100 = 8246    # Windows 11 24H2

        26200 = 8246    # Windows 11 25H2 / Windows Server 2025

        28000 = 1836    # Windows 11 26H1

    }

    if (-not $fixed.ContainsKey($currentBuild)) {
        Write-Output ("UNKNOWN - Unrecognized or unsupported Windows build: Product='{0}' DisplayVersion='{1}' Build='{2}'" -f $productName, $displayVersion, $versionString)
        exit 2
    }

    $requiredUbr = [int]$fixed[$currentBuild]

    if ($ubr -lt $requiredUbr) {
        Write-Output ("VULNERABLE - Product='{0}' DisplayVersion='{1}' Build='{2}' is below fixed floor '{3}.{4}' for CVE-2026-27910" -f $productName, $displayVersion, $versionString, $currentBuild, $requiredUbr)
        exit 1
    }
    else {
        Write-Output ("PATCHED - Product='{0}' DisplayVersion='{1}' Build='{2}' meets or exceeds fixed floor '{3}.{4}' for CVE-2026-27910" -f $productName, $displayVersion, $versionString, $currentBuild, $requiredUbr)
        exit 0
    }
}
catch {
    Write-Output ("UNKNOWN - Error determining status: {0}" -f $_.Exception.Message)
    exit 3
}

Sources

1. NVD CVE detail
2. Microsoft Security Update Guide advisory
3. CVE record
4. CISA KEV catalog
5. FIRST EPSS overview
6. Windows 10 April 14, 2026 cumulative update KB5082200
7. Windows 11 23H2 April 14, 2026 cumulative update KB5082052
8. Windows 11 24H2/25H2 April 14, 2026 cumulative update KB5083769