CVE-2026-45585 YellowKey PoC, The BitLocker Bypass That Turned WinRE Into the Attack Surface

CVE-2026-45585 is not a remote Windows bug, a BitLocker cryptography break, or a generic “encryption is dead” story. It is a Windows BitLocker security feature bypass publicly known as YellowKey. Microsoft describes it as a physical attack that can let an unauthorized attacker bypass BitLocker Device Encryption on the system storage device and gain access to encrypted data. Microsoft also confirms that a proof of concept has been made public, that public disclosure violated coordinated vulnerability disclosure best practices, and that the vulnerability was issued so defenders could apply mitigation guidance before a full security update is available. (api.msrc.microsoft.com)

That combination matters. The CVSS 3.1 score is 6.8, which can look modest if a team reads severity mechanically. The vector tells the real story: physical attack vector, low attack complexity, no privileges required, no user interaction, unchanged scope, and high confidentiality, integrity, and availability impact. Microsoft currently marks the issue as publicly disclosed, not known to be exploited, and “Exploitation More Likely.” (api.msrc.microsoft.com)

The YellowKey PoC is important because BitLocker is supposed to protect data when a device is lost, stolen, powered off, or outside normal user control. A vulnerability that needs physical access may be irrelevant to a cloud API, but it is central to laptop theft, executive travel, developer machines, border inspection, repair depots, unmanaged storage handling, and endpoint decommissioning. The attacker does not need to defeat AES. The attacker needs the recovery environment to hand over access at the wrong moment.

The short version security teams need first

Champ d'application	Current public information
CVE	CVE-2026-45585
Public name	YellowKey
Zone affectée	Windows BitLocker and Windows Recovery Environment
Type de vulnérabilité	Security feature bypass
Access required	Physical access to the target device
PoC public	Oui
Microsoft exploited status	No, according to the current MSRC record
Microsoft exploitability assessment	Exploitation More Likely
CVSS 3.1	6.8 Medium, AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Main impact	Access to data that should remain protected by BitLocker
Microsoft mitigation	Remove autofstx.exe from the WinRE BootExecute registry value using Microsoft’s interim script, then re-seal WinRE
TPM+PIN status	Microsoft says TPM+PIN makes the known vulnerability not exploitable; the researcher has claimed a separate unpublished TPM+PIN-capable variant, which is not publicly verifiable from released technical detail

The safe operational response is not to copy the public exploit into a lab and turn it into a production checklist. The useful response is to identify systems that match the affected scope, confirm BitLocker protector state, apply Microsoft’s WinRE mitigation, evaluate TPM+PIN on high-risk devices, harden physical controls, and preserve retestable evidence.

Ce qui s'est passé

The public disclosure began before Microsoft’s CVE record. On May 12, 2026, a researcher operating under the Nightmare-Eclipse and Chaotic Eclipse handles published links to YellowKey and GreenPlasma. The YellowKey GitHub repository describes the issue as a BitLocker bypass and contains a public reproduction path. For defensive writing, the existence of that repository is enough to establish public exploit availability; reproducing the exact operational steps is not necessary and would be irresponsible outside a controlled, authorized lab. (GitHub)

On May 13, the researcher published a follow-up note claiming that the public had not fully understood the root cause and claiming that TPM+PIN could also be bypassed with an unpublished variant. That claim is important to mention because it affects defender risk thinking, but it should not be treated as independently verified proof. Microsoft’s current advisory says TPM+PIN makes the vulnerability not exploitable. The correct way to write and respond is to separate Microsoft’s verified mitigation statement from the researcher’s unverified claim. (deadeclipse666.blogspot.com)

Microsoft published CVE-2026-45585 on May 19, 2026. The advisory describes YellowKey as a Windows BitLocker Security Feature Bypass Vulnerability, confirms the public PoC, states that the issue requires physical attack conditions, and provides interim mitigation guidance. Microsoft revised the advisory on May 21 to add a script that removes autofstx.exe from the WinRE BootExecute registry value and re-seals WinRE so BitLocker trust remains intact. (api.msrc.microsoft.com)

Several security outlets then summarized the risk for defenders. The Hacker News reported that the affected products include Windows 11 24H2, 25H2, 26H1 for x64 systems, Windows Server 2025, and Windows Server 2025 Server Core. Help Net Security emphasized a useful distinction from NCSC Netherlands: the vulnerability is not in BitLocker encryption itself, but in the recovery environment around it. SecurityWeek summarized the mitigation as preventing the FsTx Auto Recovery Utility from automatically starting when the WinRE image launches. (The Hacker News)

Why YellowKey is a WinRE trust-boundary bug, not an encryption break

BitLocker protects data at rest. That phrase is easy to say and easy to misunderstand. The encryption algorithm can remain sound while the surrounding platform still exposes data. Full-disk encryption depends on a chain: firmware settings, TPM measurements, boot configuration, recovery behavior, user authentication policy, key release timing, operating system state, physical custody, and administrative recovery flows.

Windows Recovery Environment, or WinRE, is part of that chain. Microsoft’s documentation describes WinRE as a recovery environment used to repair common causes of unbootable operating systems. It is based on Windows PE and is preloaded by default in Windows desktop and server installations. Microsoft’s BitLocker recovery documentation also explains that WinRE can be used to recover access to BitLocker-protected drives, and that on devices supporting certain TPM measurements, the TPM can validate WinRE as a trusted environment and unlock BitLocker-protected drives if WinRE has not been modified. (Microsoft Learn)

That design is not inherently wrong. A recovery environment must sometimes repair a system that cannot boot normally. It may need access to the OS volume to perform recovery work. The problem exposed by CVE-2026-45585 is that a trusted recovery environment becomes a sensitive execution boundary. If attacker-controlled recovery-stage behavior can influence what runs inside WinRE, the recovery environment is no longer just a repair path. It becomes an attack surface.

Public technical analysis from Eclypsium describes YellowKey as abusing behavior in WinRE to produce an unlocked command shell against a BitLocker-protected drive. The analysis points to the System Volume Information\FsTx primitive and the way WinRE handles recovery-stage transaction behavior. SecurityWeek’s summary similarly describes a path where the expected recovery UI is replaced by a command prompt, after which the underlying partition contents are accessible because BitLocker is no longer effectively protecting that session. (Eclypsium)

The important defender takeaway is not the public PoC sequence. The important takeaway is the trust-boundary failure:

Couche	Normal security expectation	YellowKey lesson
BitLocker encryption	Data remains unreadable without proper key release	Encryption can remain intact while the platform exposes the decrypted view
TPM-only unlock	TPM releases keys when measured boot state looks trusted	Trusted state assumptions can be risky if the recovery path can be influenced
WinRE	Recovery tools help repair the system	Recovery tooling must be treated as privileged attack surface
BootExecute	Early boot actions run before normal user-space controls	Early execution paths are high-value for attackers and must be minimal
Physical access	Often treated as outside the SOC’s main model	Physical access is still part of endpoint threat modeling

A stolen laptop does not care that a vulnerability is not remotely exploitable. A local shell obtained before normal Windows controls are active does not behave like an EDR alert on a running desktop. Disk encryption is a system, not a checkbox.

The affected scope, and where the public record is still uneven

The safest source of truth is Microsoft’s advisory and the NVD record. NVD currently lists CVE-2026-45585 as a Microsoft-sourced BitLocker security feature bypass and includes known affected configurations for Windows Server 2025 and Windows 11 24H2, 25H2, and 26H1 on x64. It also lists the GitHub repository as an exploit reference and Microsoft’s advisory as the vendor mitigation reference. (NVD)

The Hacker News also reports Windows Server 2025 Server Core in the affected list. That tracks Microsoft’s product-area reporting through MSRC, but defenders should always check the live vendor record for the exact SKU and build state in their environment. (The Hacker News)

There is more uncertainty around Windows Server 2022 and Windows 10. The public GitHub README claims Windows 11 plus Server 2022 and Server 2025 are affected and Windows 10 is not. Eclypsium’s analysis similarly states that researcher testing indicated Windows 11, Server 2022, and Server 2025 exposure, while Windows 10 was reported as not affected because of differences in WinRE behavior. Those statements are relevant, but they are not the same as Microsoft’s official affected-products list. In a production response, treat Microsoft and NVD as the authoritative baseline and treat researcher or third-party claims as additional signals to validate. (GitHub)

Platform or build	Status based on public sources	How to treat it operationally
Windows 11 24H2 x64	Listed by NVD as affected	Prioritize if BitLocker is enabled and the device is mobile or high value
Windows 11 25H2 x64	Listed by NVD as affected	Prioritize if deployed in endpoint fleets or executive devices
Windows 11 26H1 x64	Listed by NVD as affected	Prioritize early adopter, test, and developer hardware
Serveur Windows 2025	Listed by NVD as affected	Review physical access assumptions for branch, lab, and edge servers
Windows Server 2025 Server Core	Reported in security media as affected	Check Microsoft’s live advisory and internal inventory
Serveur Windows 2022	Claimed by researcher and some third parties	Do not dismiss; validate against vendor updates and exposure profile
Windows 10	Researcher and some third parties say not affected	Do not generalize from headlines; verify build and WinRE state separately

The worst operational mistake is to make the scope either too broad or too narrow. Too broad creates noise and burns trust. Too narrow leaves stolen-device risk untreated. The right move is to join affected OS data with BitLocker state, WinRE state, protector type, device role, and physical exposure.

Why a public PoC changes the response even without known exploitation

Microsoft currently marks CVE-2026-45585 as not exploited in the wild, while also marking it publicly disclosed and “Exploitation More Likely.” That distinction matters. “No known exploitation” does not mean “safe.” It means Microsoft has not marked observed exploitation in the advisory. Public proof of concept availability means defenders should assume technically capable actors can study, adapt, and test the bypass under controlled conditions. (api.msrc.microsoft.com)

A public PoC changes three things.

First, it reduces uncertainty. Before the PoC, a security team might reasonably ask whether the attack is theoretical. After publication, the question becomes whether the organization has exposed assets that match the conditions.

Second, it compresses response time. A physical attack vector does not require mass internet scanning. It requires a target device. The relevant attacker may be a thief, insider, contractor, repair technician, customs officer, competitor, or anyone who can briefly control a device outside the owner’s supervision.

Third, it changes communication. Security leaders cannot describe this as “a patch later” if mobile devices hold source code, legal documents, credentials, customer exports, incident notes, or cached cloud tokens. The severity is not only the CVSS number. It is the intersection between the vulnerability and the organization’s device custody model.

Scénario	Why CVE-2026-45585 matters
Stolen employee laptop	BitLocker is often the primary protection for data at rest
Executive travel device	Physical access risk is higher, and local data sensitivity is often high
Developer workstation	Local repositories, tokens, SSH keys, browser sessions, and build secrets may exist
Legal or finance endpoint	Cached documents may have regulatory or M&A sensitivity
Repair depot handoff	Device custody is delegated to third parties
Shared lab or kiosk hardware	Physical access is easier to obtain and harder to attribute
Branch server	Physical access may be easier than network compromise in some locations

A public PoC should not push defenders into unsafe testing. It should push them into safe verification. The difference is important. Unsafe testing attempts to reproduce the exploit. Safe verification confirms exposure conditions, applies vendor mitigation, and captures proof that the defensive state changed.

The Microsoft mitigation, what it actually changes

Microsoft’s interim mitigation targets WinRE behavior. The advisory says the mitigation script removes autofstx.exe from the BootExecute registry value in the offline WinRE SYSTEM hive. BootExecute runs programs very early in boot, including recovery mode, so removing that entry prevents the executable from running in a high-privilege recovery environment. Microsoft says the script mounts the WinRE image, edits the offline registry hive, commits the change, and re-seals WinRE so BitLocker trust remains intact. If the entry is not present, the script exits without making changes. (api.msrc.microsoft.com)

That is a narrow and practical fix. It does not redesign BitLocker. It does not remove the need for a future security update. It reduces the known exposure by preventing a specific recovery-stage component from launching in a sensitive context.

Microsoft also says customers do not need to revert the mitigation once the security update is available, because the security update will maintain the mitigation behavior. Microsoft further states that implementing the mitigation does not affect service availability or management operations. (api.msrc.microsoft.com)

Mitigation step	Defensive purpose	Operational caution
Run as administrator	Required to modify WinRE and the offline registry hive	Use controlled change management
Check WinRE status	Avoid modifying systems where WinRE is not enabled	Record the pre-change state
Mount WinRE image	Allows offline modification of recovery environment	Use a clean mount path
Load offline SYSTEM hive	Reads recovery environment registry state	Avoid manual registry edits unless following vendor guidance
Remove autofstx.exe de BootExecute	Prevents the component from running early in WinRE	Use Microsoft’s latest script, not copied fragments from third-party sites
Commit the WinRE image	Saves the mitigation into the recovery image	Capture success and error logs
Disable and re-enable WinRE	Re-seals the BitLocker trust chain	Retest reagentc /info afterward
Keep closure evidence	Makes remediation auditable	Store evidence with asset ID, timestamp, and operator

Security teams should resist the temptation to hand-edit this across a fleet. The mitigation touches a recovery image and BitLocker trust behavior. That is exactly the kind of change that benefits from staged rollout, tested rollback, logs, and endpoint management integration.

Safe validation commands for defenders

The following examples are defensive inventory and verification snippets. They do not reproduce the YellowKey PoC. They help a security team understand whether a device is in scope, what kind of BitLocker protector is used, whether WinRE is enabled, and whether evidence can be collected after mitigation.

Check BitLocker volume state and protector types:

Get-BitLockerVolume -MountPoint "C:" |
  Select-Object MountPoint, VolumeStatus, ProtectionStatus, EncryptionPercentage,
    @{Name="KeyProtectors"; Expression={($_.KeyProtector.KeyProtectorType -join ", ")}}

List protector IDs and types for the OS volume:

$volume = Get-BitLockerVolume -MountPoint "C:"

$volume.KeyProtector |
  Select-Object KeyProtectorType, KeyProtectorId

Check WinRE state using Microsoft’s supported command-line tool. Microsoft documents reagentc /info as the command that displays current Windows RE status and recovery image configuration. (Microsoft Learn)

reagentc /info

Collect a compact local evidence object for endpoint inventory:

$volume = Get-BitLockerVolume -MountPoint "C:"
$winreInfo = reagentc /info 2>&1

[pscustomobject]@{
  Hostname          = $env:COMPUTERNAME
  TimestampUtc      = (Get-Date).ToUniversalTime().ToString("o")
  OSVersion         = (Get-CimInstance Win32_OperatingSystem).Version
  OSBuild           = (Get-CimInstance Win32_OperatingSystem).BuildNumber
  BitLockerStatus   = $volume.ProtectionStatus
  VolumeStatus      = $volume.VolumeStatus
  KeyProtectors     = ($volume.KeyProtector.KeyProtectorType -join ",")
  WinREInfoCaptured = [bool]$winreInfo
}

Export results to JSON for fleet collection:

$evidence = [pscustomobject]@{
  Hostname        = $env:COMPUTERNAME
  TimestampUtc    = (Get-Date).ToUniversalTime().ToString("o")
  BitLockerVolume = Get-BitLockerVolume -MountPoint "C:" |
    Select-Object MountPoint, VolumeStatus, ProtectionStatus,
      @{Name="KeyProtectors"; Expression={($_.KeyProtector.KeyProtectorType -join ", ")}}
  WinRE           = (reagentc /info 2>&1) -join "`n"
}

$evidence | ConvertTo-Json -Depth 5 |
  Out-File "$env:ProgramData\SecurityEvidence\cve-2026-45585-status.json" -Encoding UTF8

For enterprise use, the output should be routed into a central system, joined to device ownership and risk labels, and reviewed for exceptions. A laptop used by a developer with TPM-only protection is not the same risk as a physically locked lab machine with no sensitive local data.

TPM-only, TPM+PIN, and the uncomfortable part of the debate

Microsoft’s BitLocker countermeasures documentation explains the tradeoff between TPM-only and stronger preboot authentication. TPM-only does not require user interaction when the TPM validation succeeds, which is convenient, but Microsoft describes it as less secure than options that require an additional authentication factor. TPM with PIN requires the user to enter a PIN before protected data can be accessed, and Microsoft states that TPMs include anti-hammering protection designed to resist brute-force attempts against the PIN. (Microsoft Learn)

For CVE-2026-45585 specifically, Microsoft’s advisory says that if TPM+PIN is used, the vulnerability is not exploitable. That is the authoritative vendor position for the known public issue. (api.msrc.microsoft.com)

The complication is the researcher’s claim that TPM+PIN does not help against an unpublished variant. That claim has not been publicly verified through released technical details. It should affect risk appetite, not replace evidence. A careful security team can say all of the following at the same time:

Statement	Niveau de confiance	Action
The public YellowKey PoC exists	Haut	Treat as public exploit availability
Microsoft says TPM+PIN blocks exploitation of CVE-2026-45585	High for Microsoft’s known scenario	Consider TPM+PIN for high-risk devices
The researcher claims a TPM+PIN-capable variant exists	Unverified publicly	Do not rely on TPM+PIN alone if Microsoft mitigation is available
The WinRE mitigation reduces known risk	High, based on Microsoft advisory	Apply through controlled rollout
Physical custody still matters	Haut	Update device handling and travel policies

TPM+PIN is not a magic phrase. It changes the unlock model by adding a preboot secret. It also adds operational cost: forgotten PINs, remote reboot friction, help desk load, recovery workflows, user training, and deployment variance. Those costs are real. But so is the risk of TPM-only on devices that leave controlled spaces.

A practical policy is to require TPM+PIN for high-risk user groups and device classes first: executives, security engineers, developers with production credentials, finance, legal, incident response, M&A, field staff, and anyone who travels with sensitive data. Lower-risk groups can be evaluated through normal endpoint risk management, but the decision should be explicit rather than inherited from default convenience.

Detection is limited because physical access changes the evidence model

YellowKey is not a typical endpoint malware event. It does not need phishing telemetry, command-and-control traffic, a browser exploit, or a remote service crash. It is closer to a recovery-path abuse scenario. That makes detection uneven.

If the attacker uses removable media and leaves no persistent artifact on the target, the host may have little useful evidence after the fact. If attack material is written to local storage, the EFI partition, or another attached volume, defenders may find suspicious recovery-related directories or filesystem artifacts. Eclypsium notes that monitoring for unexpected System Volume Information\FsTx directories on EFI System Partitions or removable media can be useful because that location is unusual in normal operations, but absence of that signal does not prove safety. (Eclypsium)

A defensive sweep for suspicious FsTx paths can look like this:

$results = @()

Get-Volume | Where-Object DriveLetter | ForEach-Object {
  $drive = "$($_.DriveLetter):"
  $path = Join-Path $drive "System Volume Information\FsTx"

  if (Test-Path $path) {
    $results += [pscustomobject]@{
      Hostname       = $env:COMPUTERNAME
      TimestampUtc   = (Get-Date).ToUniversalTime().ToString("o")
      Drive          = $drive
      SuspiciousPath = $path
      Found          = $true
    }
  }
}

$results

That check is not a complete detector. It is a weak signal hunter. Treat it as one input in a broader investigation.

Other useful evidence sources include:

Evidence source	What it can show	Limites
reagentc /info output	Whether WinRE is enabled and configured	Does not prove exploitation
BitLocker protector inventory	TPM-only vs TPM+PIN vs startup key	Does not show WinRE mitigation state by itself
Endpoint management logs	Whether mitigation script ran and succeeded	Depends on logging and collection quality
Windows event logs	Recovery, boot, BitLocker, device events	Coverage varies and may not capture pre-OS actions
USB device history	Prior removable media connections	Can be incomplete, cleared, or irrelevant
Physical custody records	Who had device access and when	Often informal or missing
Repair depot records	Third-party custody chain	May not include technical evidence
EFI partition checks	Local suspicious recovery artifacts	Requires careful access and interpretation

A useful incident question is not “Can our EDR detect YellowKey?” It is “Can we prove whether high-risk devices were exposed, mitigated, and physically controlled?” For this class of vulnerability, governance and evidence are part of detection.

A practical enterprise response playbook

The best response to CVE-2026-45585 is not a single script run. It is a short, evidence-driven program.

Build the asset scope

Start with the systems that Microsoft and NVD clearly identify, then add systems that third-party analysis suggests may be relevant. At minimum, inventory Windows 11 24H2, 25H2, 26H1 x64 systems and Windows Server 2025. Add a review bucket for Windows Server 2022 if your organization has physical exposure or high-value local data, because researcher and third-party reporting mention it even though NVD’s visible affected configurations for CVE-2026-45585 focus on Windows 11 and Server 2025. (NVD)

A simple SQL-style asset join might look like this:

SELECT
  a.hostname,
  a.owner,
  a.business_unit,
  a.os_name,
  a.os_version,
  a.os_build,
  a.device_type,
  a.last_seen,
  b.bitlocker_enabled,
  b.key_protector_types,
  b.winre_enabled,
  p.physical_risk_tier
FROM endpoint_assets a
LEFT JOIN bitlocker_inventory b
  ON a.device_id = b.device_id
LEFT JOIN physical_risk_labels p
  ON a.device_id = p.device_id
WHERE
  a.os_name LIKE 'Windows 11%'
  OR a.os_name LIKE 'Windows Server 2025%'
  OR a.os_name LIKE 'Windows Server 2022%';

Then prioritize by exposure:

Priorité	Device class	Why it moves up
P0	Lost, stolen, or recently unattended devices	Physical access may already have occurred
P0	Executive, legal, finance, security, developer devices	Local data and credential impact is high
P1	Traveling employees and field staff	Physical access risk is higher
P1	Devices with TPM-only BitLocker	Convenience mode is weaker against physical attacks
P1	Windows 11 24H2, 25H2, 26H1 with WinRE enabled	Matches current affected platform signal
P2	Branch servers and lab machines	Physical controls vary by site
P3	Physically locked, low-data endpoints	Lower exposure but still needs documented state

Confirm BitLocker and WinRE state

A device is not meaningfully in scope for the same risk if BitLocker is disabled, but that may be a separate data-loss problem. Confirm encryption state, protector type, and recovery environment state. Record the result before changing anything.

$bitlocker = Get-BitLockerVolume -MountPoint "C:"
$protectors = $bitlocker.KeyProtector.KeyProtectorType -join ","
$winre = reagentc /info 2>&1

[pscustomobject]@{
  Hostname = $env:COMPUTERNAME
  BitLockerProtection = $bitlocker.ProtectionStatus
  BitLockerVolume = $bitlocker.VolumeStatus
  ProtectorTypes = $protectors
  WinRE = ($winre -join "`n")
}

Apply Microsoft’s mitigation

Use the latest Microsoft-provided script from the advisory, not copied snippets from social media or forums. The script was updated on May 21, 2026 to make it language agnostic, and Microsoft recommends customers re-copy and run the updated version. (api.msrc.microsoft.com)

Rollout should be staged:

Phase	Cible	Success criteria
Lab	Representative Windows 11 and Server 2025 systems	Script completes, WinRE remains usable, BitLocker trust is re-sealed
Pilot	IT and security-owned endpoints	No unexpected recovery lockouts, evidence captured
High-risk rollout	P0 and P1 devices	Mitigation success rate tracked, exceptions documented
Broad rollout	Remaining in-scope systems	Endpoint management confirms completion
Retest	Sampled devices across hardware types	Protector state and WinRE status verified

Evaluate TPM+PIN for high-risk systems

Microsoft’s general BitLocker documentation already frames TPM+PIN as stronger than TPM-only because it adds a user-supplied factor before data access. For CVE-2026-45585, Microsoft says TPM+PIN makes the known vulnerability not exploitable. The operational question is not whether every endpoint can accept TPM+PIN tomorrow. The question is which device classes justify the friction. (Microsoft Learn)

A policy rollout should include:

Contrôle	Pourquoi c'est important	Common failure
TPM+PIN for high-risk users	Reduces risk from unattended or stolen devices	Too broad rollout causes help desk friction
Recovery key escrow in Entra ID or AD DS	Enables recovery without user-managed secrets	Poor access control around recovery keys
BIOS or UEFI password	Adds defense-in-depth against local boot setting changes	Inconsistent OEM configuration
Secure Boot and firmware hygiene	Supports measured boot trust	Firmware drift and unmanaged settings
Shutdown policy for travel	Reduces risks from sleep-state exposure	Users close lids instead of shutting down
Repair and logistics custody	Controls real physical access	Third-party handoffs lack records

Microsoft’s BitLocker recovery documentation recommends determining why a device entered recovery mode and notes that root cause analysis can help identify physical modification scenarios. That is the mindset security teams should apply here: recovery events are not just support tickets. They can be security signals. (Microsoft Learn)

Preserve closure evidence

For each remediated device, keep a small evidence packet:

cve: CVE-2026-45585
vulnerability_name: YellowKey
hostname: DEV-LAPTOP-042
device_owner: engineering
risk_tier: P1
os: Windows 11 25H2 x64
bitlocker:
  protection_status: enabled
  key_protectors:
    - TPM
    - PIN
winre:
  status_before: enabled
  mitigation_applied: true
  status_after: enabled
mitigation:
  source: Microsoft MSRC script
  applied_at_utc: "2026-05-25T03:15:00Z"
  applied_by: endpoint-management
  result: success
validation:
  reagentc_info_captured: true
  bitlocker_protector_inventory_captured: true
  retest_required: false
exception:
  required: false

That evidence is useful for security operations, compliance, legal review after device loss, and later retesting when Microsoft ships the full security update.

Common mistakes that will hurt the response

Treating CVSS 6.8 as low urgency

The score is medium because the attack vector is physical. That does not mean the impact is medium for a stolen laptop with source code, customer data, browser tokens, SSH keys, or incident-response material. The CVSS vector includes high confidentiality, integrity, and availability impact. (api.msrc.microsoft.com)

Saying “physical access means game over” and doing nothing

Physical access is not a reason to give up. It is a reason to define which physical access scenarios the organization actually faces. Full-disk encryption exists precisely because physical loss happens. If a bypass affects that control, it deserves a response.

Reproducing the public PoC on production devices

A public PoC should not become a casual production test. Recovery environments, BitLocker state, and boot trust are sensitive. Use official mitigations and defensive validation. If exploit reproduction is necessary, do it only in an isolated, authorized lab with non-production hardware and no real user data.

Applying TPM+PIN but skipping the WinRE mitigation

TPM+PIN is valuable, and Microsoft says it blocks the known vulnerability. That does not make the WinRE mitigation irrelevant. The safest response is layered: apply the vendor mitigation, evaluate preboot authentication, and improve custody controls.

Treating the researcher’s TPM+PIN claim as proven

The claim may be important, but public details are not enough to verify it. Defenders should track it as an uncertainty, not repeat it as established fact. Precision matters because overstatement damages credibility.

Ignoring repair, logistics, and offboarding

Many physical attacks become plausible during messy operational moments: laptop repair, lease return, executive travel, employee exit, temporary storage, shipping, and conference handling. Endpoint security teams often own the encryption policy but not the custody process. CVE-2026-45585 shows why those processes are linked.

How YellowKey compares with earlier BitLocker and WinRE issues

CVE-2026-45585 is not the first reminder that BitLocker’s security depends on recovery and boot infrastructure.

CVE-2022-41099 was also a BitLocker security feature bypass tied to WinRE update handling. Microsoft published KB5025175 with a sample PowerShell script to automate updating WinRE images on deployed Windows 10 and Windows 11 devices. The operational lesson was similar: updating the running OS is not always enough if the recovery image remains stale. (Microsoft Support)

CVE-2024-20666 was another BitLocker Security Feature Bypass Vulnerability. NVD lists a CVSS 3.1 score of 6.6 with physical attack vector, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact. The affected configurations listed by NVD span multiple Windows 10, Windows 11, and Windows Server releases. (NVD)

CVE-2024-38058 was also a BitLocker Security Feature Bypass Vulnerability. NVD lists a 6.8 CVSS 3.1 score with physical attack vector, low attack complexity, no privileges required, no user interaction, and high impact across confidentiality, integrity, and availability. Microsoft’s weakness classification for that CVE is CWE-693, Protection Mechanism Failure. (NVD)

CVE-2026-33825 is not a BitLocker vulnerability, but it is useful context for the disclosure environment around Nightmare-Eclipse. NVD describes it as a Microsoft Defender local privilege escalation caused by insufficient granularity of access control, assigns a CVSS 3.1 score of 7.8, and shows it in CISA’s Known Exploited Vulnerabilities catalog with a required action deadline. That difference matters: CVE-2026-33825 has known-exploited status through KEV, while CVE-2026-45585 is public PoC with Microsoft’s current exploited status as No. Those are different signals and should drive different response language. (NVD)

CVE	Product area	Why it is relevant	Key defender lesson
CVE-2022-41099	BitLocker and WinRE	Required attention to WinRE image updates	Recovery images are part of the security boundary
CVE-2024-20666	BitLocker	Physical-access security feature bypass	Medium CVSS can still matter for stolen-device risk
CVE-2024-38058	BitLocker	Protection mechanism failure with physical vector	Full-disk encryption depends on platform controls
CVE-2026-33825	Microsoft Defender	Local privilege escalation, KEV-listed	Public exploit and known exploitation are separate signals
CVE-2026-45585	BitLocker and WinRE	Public YellowKey PoC against recovery trust behavior	Validate WinRE, protector state, mitigation, and physical custody

The pattern is not “BitLocker is useless.” The pattern is that full-disk encryption is only as strong as the platform states that can access decrypted data. Recovery paths, firmware settings, TPM policy, and preboot authentication deserve the same seriousness as the encryption setting itself.

The AI-assisted validation angle, without turning PoC into a toy

Public PoC events create a different bottleneck for defenders. Reading the advisory is easy. Converting it into asset scope, safe validation, mitigation state, retest evidence, and a clean report is harder. That is especially true when the vulnerability sits at the intersection of endpoint management, Windows internals, physical security, and executive risk.

In authorized environments, agentic security workflows can help compress the safe side of that loop: parse the CVE signal, identify impacted asset classes, generate non-exploit validation commands, collect evidence, preserve scope boundaries, and produce retestable remediation records. Penligent’s public materials describe an AI-powered pentesting workflow oriented around finding vulnerabilities, verifying findings, generating evidence-first results, and keeping operator control over agentic workflows. (Penligent) Its writing on AI vulnerability disclosure makes the same operational point: AI can accelerate signal interpretation, but verified action still requires scope, evidence, remediation, and retesting rather than unverified model output. (Penligent)

That framing is useful for CVE-2026-45585 because the right defensive workflow is not exploit reproduction. It is controlled verification: confirm whether the device class is affected, confirm whether BitLocker and WinRE states create exposure, apply Microsoft’s mitigation, document the result, and retest. If an AI-assisted workflow cannot preserve those boundaries, it is not helping.

Detection engineering for a recovery-path vulnerability

Because YellowKey operates around recovery behavior, detection engineering needs a different posture from ordinary malware detection. A good detection plan should include state checks, artifact checks, custody checks, and exception checks.

State checks

State checks answer whether a device is currently configured in a risky way.

$os = Get-CimInstance Win32_OperatingSystem
$bl = Get-BitLockerVolume -MountPoint "C:"
$winre = reagentc /info 2>&1

[pscustomobject]@{
  Hostname = $env:COMPUTERNAME
  Caption = $os.Caption
  Version = $os.Version
  BuildNumber = $os.BuildNumber
  BitLockerProtectionStatus = $bl.ProtectionStatus
  BitLockerProtectorTypes = ($bl.KeyProtector.KeyProtectorType -join ",")
  WinREInfo = ($winre -join " | ")
}

Artifact checks

Artifact checks look for suspicious recovery-related paths. They are not proof of exploitation, and they are not proof of safety.

$paths = foreach ($vol in Get-Volume | Where-Object DriveLetter) {
  $candidate = "$($vol.DriveLetter):\System Volume Information\FsTx"
  if (Test-Path $candidate) {
    [pscustomobject]@{
      Hostname = $env:COMPUTERNAME
      Drive = "$($vol.DriveLetter):"
      Path = $candidate
      Finding = "Unexpected FsTx path present"
    }
  }
}

$paths

Custody checks

Custody checks ask who had physical control over the device.

A useful custody model should record:

Champ d'application	Pourquoi c'est important
Device ID	Links technical evidence to inventory
Owner	Helps identify business impact
Last known possession	Establishes timeline
Travel status	Raises physical access likelihood
Repair or shipping status	Identifies third-party custody
Lost or stolen report	Moves device to urgent review
BitLocker protector state	Indicates whether TPM-only was used
Mitigation state	Shows whether known exposure was reduced
Recovery key access logs	Helps assess whether keys were retrieved legitimately

Exception checks

Exceptions should expire. If a high-risk laptop cannot use TPM+PIN because of a business workflow, that exception should have an owner, a reason, a compensating control, and a review date.

exception:
  device_id: LAPTOP-1127
  cve: CVE-2026-45585
  reason: "TPM+PIN rollout delayed due to remote reboot requirements"
  compensating_controls:
    - "Microsoft WinRE mitigation applied"
    - "BIOS password enabled"
    - "Device assigned to no-travel user group"
    - "Recovery key access restricted to endpoint security admins"
  owner: endpoint-security
  review_date: "2026-06-15"

The difference between mature and immature response is not whether every device reaches the perfect state on day one. It is whether the organization can prove which devices are exposed, which are mitigated, which are excepted, and why.

A defender-first remediation checklist

Use this checklist as an operational sequence.

Étape	Action	Evidence to keep
1	Pull Windows 11 and Windows Server inventory	OS name, version, build, architecture
2	Identify Windows 11 24H2, 25H2, 26H1 x64 and Windows Server 2025	Asset list with owners
3	Add review bucket for Server 2022 if present	Rationale and validation plan
4	Enumerate BitLocker state	Protection status and protector types
5	Enumerate WinRE state	reagentc /info output
6	Prioritize high-risk physical exposure	Travel, executive, developer, legal, finance, security roles
7	Apply Microsoft’s latest mitigation script	Script version, timestamp, result
8	Re-check WinRE and BitLocker state	Post-change evidence
9	Evaluate TPM+PIN for high-risk users	Policy decision and rollout plan
10	Review recovery key access controls	Entra ID or AD DS access review
11	Add physical custody controls	Travel, repair, offboarding, lost-device process
12	Document exceptions	Owner, reason, compensating controls, expiry
13	Retest sampled systems	Independent verification record
14	Watch for Microsoft security update	Patch deployment evidence

The most important column is the evidence column. Without evidence, the response becomes a meeting note. With evidence, the response becomes defensible.

How to talk about the risk without overstating it

YellowKey is serious, but precision matters.

Do not say: “BitLocker is broken.”
Say: “A public PoC for CVE-2026-45585 shows a BitLocker security feature bypass involving Windows Recovery Environment under physical access conditions.”

Do not say: “Attackers can remotely unlock Windows laptops.”
Say: “An attacker needs physical access to a vulnerable device.”

Do not say: “TPM+PIN definitely does not work.”
Say: “Microsoft says TPM+PIN blocks the known vulnerability, while the researcher claims an unpublished TPM+PIN-capable variant that is not publicly verifiable.”

Do not say: “No exploitation means no urgency.”
Say: “Microsoft currently marks exploited as No, but the PoC is public and Microsoft assesses exploitation as more likely.”

Do not say: “Run the PoC to know if you are vulnerable.”
Say: “Use official mitigation and defensive state validation. Restrict exploit reproduction to isolated, authorized labs.”

That language discipline is not cosmetic. It prevents security teams from creating panic, false comfort, or unsafe testing pressure.

FAQ

Is CVE-2026-45585 a remote code execution vulnerability?

• No. Microsoft’s CVSS vector uses AV:P, which means the attack vector is physical.
• The attacker needs physical access to a vulnerable device.
• The risk is still meaningful because BitLocker is meant to protect data when a device is lost, stolen, or outside normal custody.
• Treat it as a stolen-device and recovery-environment risk, not as a network-facing Windows RCE. (api.msrc.microsoft.com)

Does YellowKey break BitLocker encryption itself?

• No public source shows that BitLocker’s encryption algorithm has been broken.
• The issue is better understood as a security feature bypass around the Windows Recovery Environment.
• Help Net Security cited NCSC Netherlands’ point that the vulnerability is in the recovery environment around BitLocker, not the encryption itself. (Help Net Security)
• That distinction matters because mitigation focuses on WinRE behavior and preboot policy, not changing the encryption algorithm.

Does TPM+PIN stop the YellowKey PoC?

• Microsoft’s advisory says that if TPM+PIN is used, the vulnerability is not exploitable. (api.msrc.microsoft.com)
• Microsoft’s general BitLocker documentation also describes TPM+PIN as stronger than TPM-only because it requires a user-supplied factor before data access. (Microsoft Learn)
• The researcher has claimed an unpublished TPM+PIN-capable variant, but public technical detail is not available for independent verification.
• A conservative response is to apply Microsoft’s WinRE mitigation and evaluate TPM+PIN for high-risk devices rather than choosing only one control.

Should defenders run the public YellowKey PoC to test exposure?

• Not on production devices.
• The public PoC touches recovery behavior and BitLocker-protected system access, which can create operational risk.
• Use Microsoft’s mitigation guidance and defensive checks for BitLocker protector state, WinRE status, and mitigation success.
• If exploit reproduction is required, restrict it to an isolated, authorized lab with non-production hardware and no real user data.

What should enterprise teams check first?

• Identify Windows 11 24H2, 25H2, 26H1 x64 and Windows Server 2025 systems.
• Check whether BitLocker is enabled and whether the OS volume uses TPM-only, TPM+PIN, startup key, or another protector.
• Check WinRE status with reagentc /info.
• Prioritize devices with high physical exposure or sensitive local data.
• Apply Microsoft’s latest mitigation script and keep evidence of success. (api.msrc.microsoft.com)

Is Windows 10 affected by CVE-2026-45585?

• NVD’s visible affected configurations for CVE-2026-45585 list Windows Server 2025 and Windows 11 24H2, 25H2, and 26H1 x64. (NVD)
• The researcher and some third-party analysis state that Windows 10 is not affected, reportedly because of WinRE behavior differences. (GitHub)
• Do not generalize across all BitLocker risks. Windows 10 has had other BitLocker and WinRE-related security updates, including CVE-2022-41099 and CVE-2024-20666. (Microsoft Support)

What evidence should security teams keep after mitigation?

• Asset ID, owner, OS version, OS build, and risk tier.
• BitLocker protection status and protector types before and after remediation.
• WinRE status before and after remediation.
• Microsoft mitigation script source, execution timestamp, and result.
• Any TPM+PIN policy decision or exception.
• Recovery key access review evidence.
• Retest results and exception expiry dates.

Is CVE-2026-45585 the same as CVE-2022-41099?

• No. They are separate CVEs.
• They are related in the broader sense that both involve BitLocker security and WinRE handling.
• CVE-2022-41099 required attention to updating WinRE images on deployed devices, and Microsoft provided a PowerShell-based WinRE update process. (Microsoft Support)
• CVE-2026-45585 is the YellowKey public PoC event, with Microsoft’s interim mitigation focused on removing autofstx.exe from WinRE BootExecute. (api.msrc.microsoft.com)

Fermeture

CVE-2026-45585 is a reminder that full-disk encryption is not just encryption. It is a chain of trust that includes firmware, TPM policy, preboot authentication, recovery images, early boot execution, physical custody, recovery keys, endpoint management, and evidence.

The public YellowKey PoC makes that chain visible. It shows why TPM-only convenience can be the wrong default for high-risk devices, why WinRE belongs in the endpoint attack surface, and why “physical access required” should not be dismissed when the protected asset is a laptop full of secrets.

The best response is calm and concrete: scope the affected fleet, apply Microsoft’s mitigation, consider TPM+PIN where the risk justifies the friction, improve physical custody controls, and keep proof that the work was done. The PoC is public. The response should be just as verifiable.