The YellowKey Zero-Day: Why Your BitLocker Setup Just Failed You

5 min. read

If your company relies on the default BitLocker configuration for Windows laptops, you have a massive physical security problem on your hands. A security researcher going by the name Chaotic Eclipse recently got tired of waiting for Microsoft to fix a severe flaw and dropped a fully functional zero-day exploit on GitHub. The exploit is called YellowKey. It allows anyone with brief physical access to a Windows 11 or Server 2025 machine to completely bypass full-disk encryption.

An attacker does not need a stolen password or the massive alphanumeric recovery key. They just need a USB stick and the ability to press the control key during boot.

Microsoft formally acknowledged the flaw this morning, tracking it as CVE-2026-45585, but they did not provide an actual patch. Instead, they handed system administrators a manual mitigation guide to bandage the bleeding.

To understand why this is so devastating, you have to look at how modern Windows handles encryption. Most businesses deploy BitLocker in a TPM-only configuration. This means the encryption key is tied to the hardware Trusted Platform Module on the motherboard. When you turn the laptop on, the TPM verifies the boot sequence is normal and automatically unlocks the drive before Windows loads. This provides a seamless experience for the user. It also means the drive is vulnerable the second the power button is pressed if an attacker can hijack the boot sequence.

YellowKey does exactly that by targeting the Windows Recovery Environment. WinRE is a hidden partition designed to help you fix a broken operating system. When an attacker boots the target machine into WinRE with a specifically crafted USB drive inserted, a bizarre vulnerability triggers. The USB drive contains manipulated NTFS transaction log files inside a folder named FsTx. The recovery environment automatically scans for these logs and attempts to replay them.

Because of a massive oversight in how WinRE handles cross-volume file modifications, replaying those logs deletes a critical file called winpeshl.ini. That file is responsible for loading the standard recovery user interface. Without it, the recovery environment panics and drops the user straight into an unrestricted command prompt. Because the TPM already verified the initial boot sequence and unlocked the drive, that command prompt has full read and write access to all your encrypted data.

The discoverer actually called this vulnerability a backdoor. They noted that the specific component allowing the bypass exists in a stripped-down, safe form on Windows 10 but was drastically changed for Windows 11. Whether it is an intentional backdoor or just incredibly sloppy engineering, the result is the same. Your data is exposed.

Since Microsoft has not released an actual security update yet, they are telling IT teams to manually modify the WinRE image. The official mitigation requires administrators to mount the hidden recovery partition, load the system registry hive into memory, and delete the autofstx.exe entry from the BootExecute registry key. This stops the auto-recovery utility from launching and replaying the malicious files.

For MSPs managing thousands of endpoints, manually mounting recovery images via PowerShell scripts is a logistical nightmare.

There is a much simpler, permanent fix that you should have implemented years ago anyway. You need to abandon the TPM-only configuration. Switch your fleet to require a TPM+PIN setup. This forces the user to enter a short numerical PIN at the BIOS level before the TPM will release the decryption key to the operating system. Even if an attacker uses the YellowKey USB drive to break the recovery environment, the drive itself will remain locked because the boot sequence stalls waiting for the user's PIN.

Do not wait for Patch Tuesday to address this. If a client laptop gets stolen out of a rental car today, the thief already has the tools to read every file on the disk. Deploy the PIN requirement through Intune or your RMM immediately and stop trusting default configurations.