YellowKey: BitLocker wasn't the boundary — WinRE was the door
Microsoft spent years telling enterprises that BitLocker plus TPM equals “stolen laptop? shrug.” YellowKey (CVE-2026-45585) is the reminder that encryption at rest is only as honest as the recovery path that unlocks it.
Disclosed in May 2026 by a researcher operating as Chaotic Eclipse / Nightmare-Eclipse,
YellowKey is not a crypto break. It is a WinRE behavior abuse that leaves you holding
cmd.exe against a volume BitLocker already transparently decrypted.
Kevin Beaumont and Will Dormann independently validated the public proof-of-concept. Microsoft’s own advisory acknowledges the exploit was published “violating coordinated vulnerability best practices” — which is MSRC polite for someone dropped working code and we are scrambling.
The attack in one paragraph
An attacker with physical access prepares storage containing a crafted
System Volume Information\FsTx tree. The target boots into the Windows Recovery Environment
(WinRE) — Shift+Restart, recovery USB, evil maid, stolen drive mounted offline, take your pick.
During WinRE startup, the FsTx Auto Recovery utility (autofstx.exe) is listed in the
Session Manager’s BootExecute registry value inside the recovery image. It replays
Transactional NTFS (TxF) logs from the malicious FsTx folder. Those logs delete
winpeshl.ini, the file that tells WinRE which shell to launch.
With winpeshl.ini gone, WinRE falls back to cmd.exe. By then the OS volume has already
been unlocked by the TPM seal — the attacker inherits a fully readable filesystem, not a
locked BitLocker prompt.
No recovery key. No BitLocker PIN prompt in the vulnerable configuration. Just a shell.
Why this feels “backdoor-shaped”
Eclypsium and the researcher both noted an asymmetry that makes defenders uncomfortable:
-
The running Windows installation does not expose the same exploitable FsTx replay surface the same way WinRE does.
-
The recovery image carries
autofstx.exein BootExecute — a component whose job is to replay transaction logs from attached volumes during recovery boot.
Whether you call that a backdoor or “recovery plumbing that never got threat-modeled,” the trust boundary moved. Teams modeled BitLocker as the gate. The gate was already open once WinRE started on a TPM-only machine.
Chaotic Eclipse framed the release accordingly: this is not “I broke AES.” This is “your recovery environment is a second front door.”
Delivery paths (physical access is broader than you think)
The public PoC demonstrated multiple paths to the same primitive:
- USB stick — FsTx payload on removable media, boot into WinRE (Shift+Restart, hold Ctrl during reboot tricks, etc.).
- EFI System Partition — write the same structure to the internal ESP; no USB required if you already have admin or ~30 seconds alone with the machine.
- Offline disk — pull the drive, mount elsewhere, plant FsTx, reinsert, recover boot.
If your threat model is only “encrypted at rest when powered off,” YellowKey is a direct hit on travel laptops, hot-desk machines, and any device that sleeps in a hotel room with TPM-only BitLocker.
TPM+PIN: Microsoft’s line vs. the researcher’s claim
Microsoft’s mitigation FAQ is blunt:
“I am using TPM+PIN, am I at risk?” — No, if you are using TPM+PIN the vulnerability is not exploitable.
Chaotic Eclipse publicly disagreed, stating a TPM+PIN bypass variant exists — but did not publish that PoC. Treat Microsoft’s statement as the official posture; treat the researcher’s claim as a forward-looking indicator, not FUD and not something to ignore in high-threat travel-laptop programs.
Defense in depth still means: TPM+PIN, firmware/BIOS admin password, disable boot-from-USB where policy allows, and assume WinRE tampering is in scope for lost-device scenarios.
Mitigations (May–June 2026 timeline)
Microsoft assigned CVE-2026-45585 (CVSS 6.8) and shipped guidance before the full patch landed in June 2026 Patch Tuesday:
Registry / WinRE image workaround
Remove autofstx.exe from the BootExecute value inside the WinRE image’s registry
hive. Microsoft published a mitigation script for this. Effect: malicious FsTx folders on USB are
never replayed during recovery boot.
Operational gotcha: Windows Update can reintroduce the BootExecute entry when WinRE is refreshed. Build WinRE verification into your patch Tuesday checklist — not a one-and-done script.
BitLocker policy
Move from TPM-only to TPM+PIN (or stronger) on high-value mobile assets. Microsoft says this closes the exploit path entirely for YellowKey as published.
Detection ideas (imperfect)
-
System Volume Information\FsTxon the ESP or OS volume where it has no legitimate reason to exist. -
Modified
winpeshl.initimestamps inside the WinRE image. -
If the attacker boots from external media only, host-side forensics may see nothing — plan accordingly.
What YellowKey is not
-
Not a remote code execution bug — physical access (or equivalent) is required.
-
Not Windows 10 — reporting centers on Windows 11 and Windows Server 2025 (plus related WinRE builds).
-
Not “BitLocker is broken” — the crypto did its job; the recovery trust model did not.
The bigger picture
YellowKey arrived in the middle of Nightmare-Eclipse’s broader zero-day wave — Defender LPEs, CTFMON abuse, filter-driver regressions — all timed the day after Patch Tuesday so defenders sat in the gap until the next cycle. See the companion draft: Nightmare Eclipse dropped a summer of Windows zero-days for the full release scorecard and the disclosure drama.
For enterprise teams the lesson is narrow and actionable:
BitLocker protects the disk. WinRE protects nothing if it can unlock the disk first.
Patch June 2026. Run the WinRE mitigation script on anything that missed the train. Put a PIN on every laptop that crosses a TSA checkpoint.
References (starting points, not exhaustive):