Microsoft is aware of a security feature bypass vulnerability in Windows publicly referred to as &quot

CVE-2026-45585, aka *YellowKey*, is a Windows BitLocker security-feature bypass tied to WinRE trust behavior. Officially tracked affected platforms are Windows 11 24H2/25H2/26H1 x64 and Windows Server 2025, with a public PoC showing a crafted FsTx payload on removable media or EFI storage can trigger a shell in WinRE and expose a BitLocker-protected volume. Microsoft explicitly states systems using TPM+PIN are not exploitable, which sharply narrows the vulnerable population inside mature fleets.

Microsoft's MEDIUM 6.8 baseline is broadly fair, and if anything slightly generous for enterprise patch prioritization. The impact is ugly—loss of confidentiality of data at rest on a lost or stolen device—but the decisive friction is attacker position: this is physical-only, offline, per-device exploitation, not something an internet adversary can spray across 10,000 hosts. Public PoC availability keeps it important, especially for mobile fleets, but it is still not a front-of-queue remote compromise issue.

Why this verdict

• Downgrade for attacker position: the vendor starts at 6.8, but AV:P means the adversary must already have the device or its storage in hand. That implies theft, insider access, border seizure, repair-chain access, or a similar high-friction precondition.
• Downgrade for reachable population: this is not externally scannable and not remotely sprayable. In a 10,000-host enterprise, the exposed slice is the subset of affected Windows builds using TPM-only BitLocker on physically mobile assets.
• Hold at medium because the impact is real and the PoC is public: once the attacker reaches the device, the control being bypassed is your data-at-rest boundary. For laptop-heavy fleets, that is not academic risk.

Why not higher?

There is no unauthenticated remote path, no internal lateral-movement shortcut, and no tenant-wide or domain-wide blast radius. Each extra prerequisite—physical possession, reboot access, affected BitLocker configuration, unmitigated WinRE path—pushes this down from emergency patch territory.

Why not lower?

This is not harmless edge-case noise because it directly defeats a security boundary many enterprises rely on for lost or stolen devices. Public PoC plus high confidentiality impact on common mobile endpoints keeps it above backlog-only hygiene.

1. Move TPM-only devices to TPM+PIN — Use this first on executive, travel, contractor, and high-data-sensitivity laptops. Microsoft states TPM+PIN is not exploitable; for a MEDIUM verdict there is no mitigation SLA, so treat this as targeted hardening during the normal remediation window rather than an emergency fleet scramble.
2. Audit BitLocker protector state fleet-wide — Identify affected Windows 11/Server 2025 assets where the OS volume uses plain TPM without pre-boot auth. This is the fastest way to reduce the population that actually matters and should be completed early in the 365-day remediation window.
3. Apply Microsoft's WinRE mitigation on higher-risk endpoints — Where operationally tolerable, implement the vendor's interim WinRE mitigation on laptops that leave controlled facilities. Because the verdict is MEDIUM, there is no mitigation SLA; prioritize based on theft exposure and data sensitivity.
4. Tighten physical custody controls — Lost/stolen-device workflows, secure storage, shipping-chain controls, and repair/vendor handling materially cut the only realistic initial-access path. For this CVE, physical security is not a side note; it is a primary exploit blocker.

Run this on the target Windows endpoint in an elevated PowerShell session (Run as Administrator). Example: powershell.exe -ExecutionPolicy Bypass -File .\Test-YellowKey.ps1. It needs local admin rights to query BitLocker state. PATCHED in this script means not exploitable / effectively mitigated for YellowKey today, usually because the device uses TPM+PIN or stronger pre-boot auth; it does not mean Microsoft has shipped a permanent security update.

# Test-YellowKey.ps1

# Detect likely exposure to CVE-2026-45585 / YellowKey on the local Windows host.

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


$ErrorActionPreference = 'Stop'

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

try {
    $os = Get-CimInstance Win32_OperatingSystem
    $cs = Get-CimInstance Win32_ComputerSystem
    $productType = $os.ProductType   # 1=Workstation, 2=DC, 3=Server

    $caption = [string]$os.Caption
    $build = [int]$os.BuildNumber
    $displayVersion = (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -ErrorAction SilentlyContinue).DisplayVersion

    $isServer2025 = ($productType -ne 1 -and $caption -match 'Server 2025')
    $isWin11 = ($productType -eq 1 -and $caption -match 'Windows 11')

    # Officially tracked affected workstation releases are Win11 24H2/25H2/26H1 x64.

    $isAffectedClientRelease = $false
    if ($isWin11 -and $cs.SystemType -match 'x64') {
        if ($displayVersion -in @('24H2','25H2','26H1')) {
            $isAffectedClientRelease = $true
        }
    }

    $isAffectedOS = $isServer2025 -or $isAffectedClientRelease
    if (-not $isAffectedOS) {
        Write-Result -State 'PATCHED' -Reason 'Host is not on an officially tracked affected OS/release for YellowKey.' -Code 0
    }

    $osDrive = $env:SystemDrive.TrimEnd(':') + ':'
    $blv = Get-BitLockerVolume -MountPoint $osDrive -ErrorAction Stop

    if ($null -eq $blv) {
        Write-Result -State 'UNKNOWN' -Reason 'Unable to read BitLocker state for the OS volume.' -Code 2
    }

    if ($blv.VolumeStatus -eq 'FullyDecrypted' -or $blv.ProtectionStatus -eq 'Off') {
        Write-Result -State 'PATCHED' -Reason 'BitLocker protection is not active on the OS volume; YellowKey BitLocker bypass is not applicable as configured.' -Code 0
    }

    $kpTypes = @()
    if ($blv.KeyProtector) {
        $kpTypes = $blv.KeyProtector | ForEach-Object { $_.KeyProtectorType }
    }

    if (-not $kpTypes -or $kpTypes.Count -eq 0) {
        Write-Result -State 'UNKNOWN' -Reason 'BitLocker is enabled but key protector types could not be determined.' -Code 2
    }

    $hasTpmOnly = $kpTypes -contains 'Tpm'
    $hasTpmPin = ($kpTypes -contains 'TpmPin') -or ($kpTypes -contains 'TpmAndPin')
    $hasTpmStartupKey = ($kpTypes -contains 'TpmStartupKey') -or ($kpTypes -contains 'TpmAndStartupKey')
    $hasTpmPinStartupKey = ($kpTypes -contains 'TpmPinStartupKey') -or ($kpTypes -contains 'TpmAndPinAndStartupKey')

    # Microsoft states TPM+PIN is not exploitable. Treat any stronger pre-boot auth than TPM-only as PATCHED/mitigated.

    if ($hasTpmPin -or $hasTpmStartupKey -or $hasTpmPinStartupKey) {
        Write-Result -State 'PATCHED' -Reason ('Affected OS, but BitLocker pre-boot auth is stronger than TPM-only. Key protectors: ' + ($kpTypes -join ', ')) -Code 0
    }

    if ($hasTpmOnly) {
        Write-Result -State 'VULNERABLE' -Reason ('Affected OS with TPM-only BitLocker protector on OS volume. Key protectors: ' + ($kpTypes -join ', ')) -Code 1
    }

    Write-Result -State 'UNKNOWN' -Reason ('Affected OS, BitLocker enabled, but protector mix is uncommon or could not be mapped cleanly. Key protectors: ' + ($kpTypes -join ', ')) -Code 2
}
catch {
    Write-Result -State 'UNKNOWN' -Reason $_.Exception.Message -Code 2
}

Sources

1. NVD CVE-2026-45585
2. Microsoft Security Update Guide entry
3. Public YellowKey PoC repository
4. Microsoft Learn - BitLocker overview
5. Microsoft Learn - BitLocker countermeasures
6. CISA Known Exploited Vulnerabilities Catalog
7. NCSC advisory NCSC-2026-0165