Improper access control in Software Protection Platform

CVE-2025-59199 is an SPP local privilege escalation in Windows' Software Protection Platform: a user who already has local code execution with low privileges can abuse improper access control to jump to a more privileged context, plausibly SYSTEM. Public Microsoft/NVD text is thin, but the affected range is broad: Windows 10 1809/21H2/22H2, Windows 11 22H2/23H2/24H2/25H2, Windows Server 2019/2022/2025, and Server 23H2 Core builds prior to the October 14, 2025 fixes.

Microsoft's HIGH 7.8 is technically fair in a CVSS vacuum because successful exploitation gives full host impact, but it overstates enterprise patch urgency. The decisive downgrade is the attack position: AV:L and PR:L mean the attacker must already be on the box with a valid low-privileged context, so this is a *post-initial-access amplifier*, not an exposure path. No KEV listing, no active exploitation evidence, no public PoC in straightforward searches, and a very low EPSS all push it down to MEDIUM for fleet prioritization.

Why this verdict

• Vendor baseline starts at 7.8 because impact is real: if exploitation succeeds, the attacker can reach full host compromise.
• AV:L + PR:L is the decisive downgrade: the attacker already needs local execution and a valid low-privileged context, which implies a prior compromise stage or legitimate access.
• Reachable population is broad in software terms but narrow in attack terms: many Windows builds are affected, yet only systems where the attacker is already on-box can be attacked.
• Modern controls should break the chain earlier: EDR, app control, email protections, MFA, and hardening target the prerequisite foothold stage, not the SPP bug itself.
• Threat intel is quiet: no KEV, no public exploitation evidence found, no public PoC found, and EPSS is very low.

Why not higher?

This is not remotely reachable, not pre-auth, not internet-exposed, and not wormable. There is also no public exploitation signal that would justify treating it like a live-fire Windows emergency despite the high technical impact on a single host.

Why not lower?

Dropping this to LOW would ignore how often Windows LPEs are used to turn commodity user-level access into durable control. The affected population is large, the impact after success is severe, and this class of bug is operationally useful for ransomware operators and post-exploitation teams even without public KEV evidence.

1. Tighten local admin and user-rights sprawl — Reduce the value of a successful LPE by removing standing local admin, limiting logon rights on servers, and enforcing least privilege on admin workstations. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but apply this sooner anywhere patching will lag.
2. Harden high-value Windows tiers first — Prioritize EDR self-protection, Credential Guard/LSA protection, application control, and restricted admin workflows on jump hosts, identity infrastructure, and admin endpoints. These controls blunt the payoff of SYSTEM-level escalation even if the vulnerable build remains temporarily present; with no mitigation SLA for MEDIUM, use this as risk reduction where immediate patching is impractical.
3. Alert on post-escalation behavior — Tune detections for service creation, scheduled task abuse, LSASS access, token abuse, security tool tampering, and abnormal parent-child process chains from user context into privileged actions. This does not stop the bug directly, but it catches the part attackers actually monetize; again, no mitigation SLA applies here, so deploy as part of normal detection engineering.
4. Verify Windows build compliance centrally — Use your patch and vuln-management platforms to baseline the fixed build thresholds and identify stragglers by OS family, especially unmanaged servers and long-lived VDI images. Because this is MEDIUM, track it into the 365-day remediation window rather than creating emergency change noise.

Run this on the target Windows host or through your remote management tooling in the same OS context you use for inventory. Example: powershell -ExecutionPolicy Bypass -File .\Test-CVE-2025-59199.ps1; standard user rights are usually enough because it only reads OS version/build data.

# Test-CVE-2025-59199.ps1

# Checks whether the current Windows build is below the fixed threshold for CVE-2025-59199.

# Output: VULNERABLE / PATCHED / UNKNOWN

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


$ErrorActionPreference = 'Stop'

function Write-Result {
    param(
        [string]$State,
        [string]$Message,
        [int]$Code
    )
    Write-Output "$State - $Message"
    exit $Code
}

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

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

    # Fixed thresholds from Microsoft/NVD/CNA data for CVE-2025-59199

    $fixed = @{
        17763 = 7919
        19044 = 6456
        19045 = 6456
        20348 = 4294
        22621 = 6060
        22631 = 6060
        25398 = 1913
        26100 = 6899
        26200 = 6899
    }

    if (-not $fixed.ContainsKey($currentBuild)) {
        Write-Result -State 'UNKNOWN' -Message "Unsupported or unaffected build family detected: $productName $displayVersion ($buildString)" -Code 2
    }

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

    if ($ubr -lt $requiredUbr) {
        Write-Result -State 'VULNERABLE' -Message "$productName $displayVersion build $buildString is below fixed threshold $currentBuild.$requiredUbr for CVE-2025-59199" -Code 1
    }
    else {
        Write-Result -State 'PATCHED' -Message "$productName $displayVersion build $buildString meets or exceeds fixed threshold $currentBuild.$requiredUbr for CVE-2025-59199" -Code 0
    }
}
catch {
    Write-Result -State 'UNKNOWN' -Message "Version check failed: $($_.Exception.Message)" -Code 3
}

Sources

1. Microsoft Security Update Guide - CVE-2025-59199
2. NVD - CVE-2025-59199
3. OpenCVE mirror of Microsoft CNA record
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS project
6. Microsoft Support KB5066586 - OS Build 17763.7919
7. Microsoft Support KB5066791 - OS Builds 19044.6456 and 19045.6456
8. Microsoft Support KB5066793 / KB5066835 - OS Builds 22621.6060, 22631.6060, 26100.6899, 26200.6899