"If you did everything properly, a shell will spawn with unrestricted access to the BitLocker protected volume," the researcher noted in a GitHub post.
CVE-2026-45585 (YellowKey): the vulnerability and scope
Microsoft on Tuesday released a mitigation for a publicly disclosed BitLocker bypass referred to as "YellowKey," now tracked as CVE-2026-45585. The flaw carries a CVSS score of 6.8 and has been characterized as a security feature bypass affecting BitLocker-protected volumes.
According to Microsoft's advisory, the issue impacts the following platforms: Windows 11 version 26H1 for x64-based Systems, Windows 11 version 25H2 for x64-based Systems, Windows 11 version 24H2 for x64-based Systems, Windows Server 2025, and Windows Server 2025 (Server Core installation). Microsoft also said that a proof-of-concept for the vulnerability has been made public, which it described as "violating coordinated vulnerability best practices."
How YellowKey works, as described by the discloser
The vulnerability was disclosed by a security researcher using the handle Chaotic Eclipse (aka Nightmare-Eclipse). The researcher outlined an exploit path that relies on placing specially crafted "FsTx" files on a USB drive or an EFI partition, inserting that drive into a target machine that has BitLocker enabled, rebooting to the Windows Recovery Environment (WinRE), and triggering a shell by holding down the CTRL key.
Microsoft warned that successful exploitation could permit "an attacker with physical access to sidestep the BitLocker Device Encryption feature on the system storage device and gain access to encrypted data."
Microsoft's mitigation: editing WinRE and blocking autofstx.exe
Microsoft published a step-by-step mitigation that requires administrators to modify the WinRE image on each affected device. The principal actions in the mitigation are:
- Mount the WinRE image on each device.
- Mount the system registry hive of the mounted WinRE image.
- Modify BootExecute by removing the "autofstx.exe" value from the Session Manager's BootExecute REG_MULTI_SZ value.
- Save and unload the registry hive.
- Unmount and commit the updated WinRE image.
- Reestablish BitLocker trust for WinRE.
Security researcher Will Dormann explained the effect of these steps: "Specifically, you prevent the FsTx Auto Recovery Utility, autofstx.exe, from automatically starting when the WinRE image launches. With this change, the Transactional NTFS replaying that deletes winpeshl.ini no longer happens." The mitigation therefore targets the component that the PoC relies on to gain a shell during WinRE boot.
Changing BitLocker protectors: TPM-only versus TPM+PIN
Microsoft emphasized an additional defensive configuration: switching BitLocker-protected devices from "TPM-only" to "TPM+PIN" protectors. When configured for TPM+PIN, a startup PIN is required to decrypt the drive at boot, which Microsoft said will "effectively back YellowKey attacks" on already encrypted devices.
Administrators can make this change via PowerShell, the command line, or the control panel. For devices that are not yet encrypted, Microsoft advises enabling the "Require additional authentication at startup" option through Microsoft Intune or Group Policies and ensuring the "Configure TPM startup PIN" policy is set to "Require startup PIN with TPM."
What this means for technologists, administrators, and end users
- Technologists and security teams: The mitigation requires hands-on modification of WinRE images on each device; teams will need processes to mount, edit, and reestablish BitLocker trust for WinRE images at scale to prevent the FsTx Auto Recovery Utility from launching automatically.
- Enterprise administrators and procurement leaders: Devices already encrypted with BitLocker using TPM-only protectors will be advised to roll out TPM+PIN configuration changes via PowerShell, command line, control panel, or centralized management like Intune and Group Policy to provide an added startup authentication requirement.
- End users and desktop administrators: On affected machines, the practical defense is to require a startup PIN with TPM. For organizations, enabling "Require additional authentication at startup" and setting "Configure TPM startup PIN" to "Require startup PIN with TPM" on unencrypted devices is the recommended preventive step.
YellowKey is notable for its reliance on physical access and a small but impactful chain of actions executed in WinRE; the published proof-of-concept and Microsoft's mitigation together make the immediate technical remedies clear. The real test now is operational: whether organizations will apply the WinRE modifications and shift protectors to TPM+PIN quickly enough to limit successful exploitation.
Original reporting: The Hacker News — Microsoft Releases Mitigation for YellowKey BitLocker Bypass CVE-2026-45585 Exploit
