Microsoft issues YellowKey BitLocker mitigation, urges TPM+PIN

Microsoft released a mitigation for YellowKey (CVE-2026-45585), a BitLocker bypass using crafted FsTx files to spawn a WinRE shell; it urges switching from TPM-only to TPM+PIN.

Microsoft on Tuesday published a mitigation for YellowKey, tracked as CVE-2026-45585, a vulnerability that can bypass BitLocker encryption when an attacker has physical access to a device. The flaw carries a CVSS score of 6.8. Microsoft said the proof-of-concept code was made public, violating coordinated disclosure practices.

The issue affects Windows 11 for x64-based systems (versions 24H2, 25H2 and 26H1) and Windows Server 2025, including Server Core installations. Researcher Chaotic Eclipse (also known as Nightmare-Eclipse) described the exploit sequence: an attacker places specially crafted FsTx files on a removable drive or on an EFI partition, plugs the drive into a target machine with BitLocker enabled, reboots into the Windows Recovery Environment (WinRE) and holds the CTRL key to trigger an elevated shell with access to the encrypted volume.

Microsoft provided manual mitigation steps for administrators while it works on a software fix. The vendor’s guidance requires mounting each device’s WinRE image, loading the system registry hive from the mounted image, removing the autofstx.exe entry from the Session Manager BootExecute REG_MULTI_SZ value, saving and unloading the registry hive, and committing the updated WinRE image. After updating the image, administrators must reestablish BitLocker trust for the recovery environment.

Security researcher Will Dormann said preventing the FsTx Auto Recovery Utility (autofstx.exe) from starting stops the Transactional NTFS replay that deletes winpeshl.ini and leads to the unauthorized shell. Dormann also recommended switching BitLocker protectors from TPM-only to TPM+PIN to block the attack.

Microsoft advised users to change existing TPM-only BitLocker protectors to TPM+PIN using PowerShell, the command line or the Control Panel. Requiring a startup PIN adds an authentication factor at boot and prevents an attacker with physical access from decrypting the drive without the PIN. For devices not yet encrypted, administrators should enable the Require additional authentication at startup option through Microsoft Intune or Group Policy and set Configure TPM startup PIN to require a startup PIN with TPM.

The public proof-of-concept published by Chaotic Eclipse increases the potential for active exploitation against unpatched or unmitigated systems, Microsoft warned. The company did not release a patch in the advisory but supplied the registry and WinRE image modifications as immediate mitigations.

Chaotic Eclipse posted technical details and a demonstration on GitHub showing how crafted FsTx files interact with WinRE to achieve code execution. Organizations should update WinRE images used for recovery, enforce BitLocker protectors that require a PIN in addition to TPM, and review device configuration policies to ensure startup PIN requirements are applied.

Articles by this author