Microsoft on Tuesday released a mitigation for a BitLocker bypass vulnerability named YellowKey following its public disclosure last week.
The zero-day flaw, now tracked as CVE-2026-45585, carries a CVSS score of 6.8. It has been described as a BitLocker security feature bypass.
“Microsoft is aware of a security feature bypass vulnerability in Windows publicly referred to as ‘YellowKey,'” the tech giant said in an advisory. “The proof of concept for this vulnerability has been made public, violating coordinated vulnerability best practices.”
The issue impacts Windows 11 version 26H1 for x64-based Systems, Windows 11 Version 24H2 for x64-based Systems, Windows 11 Version 25H2 for x64-based Systems, Windows Server 2025, and Windows Server 2025 (Server Core installation).
YellowKey was disclosed by a security researcher named Chaotic Eclipse (aka Nightmare-Eclipse). It essentially involves placing specially crafted ‘FsTx’ files on a USB drive or EFI partition, plugging the USB drive into the target Windows computer with BitLocker protections turned on, rebooting into the Windows Recovery Environment (WinRE), and triggering a shell with unrestricted access by holding down the CTRL key.
“If you did everything properly, a shell will spawn with unrestricted access to the BitLocker protected volume,” the researcher noted in a GitHub post.
Redmond noted 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.
“To break encryption, YellowKey abuses a behavioral trust assumption in the recovery interface, allowing attackers to spawn an unrestricted shell with full access to the encrypted volume during the pre-boot recovery sequence,” LevelBlue said. “And because YellowKey doesn’t require software installation, existing credentials, or network access to break encryption, any machine that has a USB port and can be rebooted can be a target.”
To address the risk, the following mitigations have been outlined:
- Mount the WinRE image on each device.
- Mount the system registry hive of the mounted WinRE image.
- Modify BootExecute by removing “autofstx.exe” value from Session Manager’s BootExecute REG_MULTI_SZ value.
- Save and unload Registry hive.
- Unmount and commit the updated WinRE image.
- Reestablish BitLocker trust for WinRE.
“Specifically, you prevent the FsTx Auto Recovery Utility, autofstx.exe, from automatically starting when the WinRE image launches,” security researcher Will Dormann said. “With this change, the Transactional NTFS replaying that deletes winpeshl.ini no longer happens. It also recommends switching from TPM-only to TPM+PIN.”
Microsoft also emphasized that users can be safeguarded against exploitation by configuring BitLocker on already encrypted devices with “TPM-only” protector by switching to “TPM+PIN” mode via PowerShell, the command line, or the control panel. This will require a PIN to decrypt the drive at startup, effectively backing YellowKey attacks.
On devices that are not encrypted, administrators are advised to enable the “Require additional authentication at startup” option via Microsoft Intune or Group Policies and ensure that “Configure TPM startup PIN” is set to “Require startup PIN with TPM.”
Update
In a new analysis published on May 22, 2026, LevelBlue said YellowKey eliminates the need for specialized tooling and operates entirely through native Windows functionality. “It requires only brief physical access and does not introduce persistent hardware artifacts,” it said. “As a result, it becomes viable across a wider range of real-world scenarios, including device theft, border inspections, insider access, and supply chain exposure.”
It further noted that YellowKey reinforces how initial access to a decrypted volume can be expanded to a full-blown system control through a SYSTEM-level command shell, adding the WinRE component, “autofstx.exe,” plays a crucial role in the exploit, as it’s executed via the BootExecute registry value within the WinRE environment.
“This behavior enables cross-volume TxF transaction replay in a high-privilege early boot context, forming the core mechanism behind the YellowKey exploit,” LevelBlue said.
