YellowKey The BitLocker failure that could allow an attacker to unlock your unit with only physical access

Microsoft has published a mitigation for a BitLocker security omission vulnerability known as YellowKey (CVE-2026-45585) after his concept test was publicly leaked and the coordinated disclosure process was broken. The failure, with a CVSS score of 6.8, allows an attacker with physical access to use specially manipulated files ("FsTx") in a USB drive or in the EFI partition, to restart the machine in the Windows Recovery Environment (WinRE) and to cause the execution of a utility that, according to the researcher, opens a shell with unrestricted access to the volume encrypted by BitLocker.

It is important to stress that This attack requires physical access and the ability to force WinRE boot from external means, which partially limits the threat radius to equipment theft scenarios, access to server rooms or environments with laxity boot policies. However, the existence of a public PoC increases the operational risk: adversaries with technical knowledge and physical access can automate commitment tests without the need to investigate vulnerability from scratch. For additional technical coverage and journalistic monitoring, covers such as BleepingComputer have documented the disclosure and response of Microsoft: BleepingComputer on YellowKey.

Microsoft has described a modification-based mitigation of the WinRE: you have to mount the WinRE image, load your registration fig, remove the "autofstx.exe" input of the Session Manager BootExecute value, save and download the fig, and recompromise the image on the device. This prevents the FsTx utility from running automatically when WinRE starts. In addition, the company recommends to change the BitLocker protectors from TPM-only to TPM + PIN, so that the volume unlocking requires a PIN in the boot and does not depend only on the TPM module. The official documentation of BitLocker in Microsoft can help plan these changes: BitLocker documentation in Microsoft Docs.

For teams and managers, the practical implications are twofold: first, mitigation in WinRE images must be applied and widely deployed; second, start-up policies and physical security must be reviewed. Switching to TPM + PIN drastically reduces the effectiveness of YellowKey because even with WinRE committed the attacker will not be able to decipher the unit without knowing the PIN. Microsoft describes options to impose this requirement from Intune or Group Policies ("Require additional authentication at startup" and "Configure TPM startup PIN").

It is not enough just to mitigate at the software level: strengthen physical and firmware control It's crucial. I recommend disabling the boot from USB when it is not necessary, protecting UEFI / BIOS firmware with password, forcing Secure Boot and registering who has physical access to critical machines. These measures reduce the opportunities for an attacker to insert manipulated means or restart servers to invoke WinRE with external means.

At the operational level, organizations should prioritize the identification and mapping of WinRE images used by the fleet, integrate checks into the image management cycle and automate the modification proposed by Microsoft to prevent human errors. It is also appropriate to review incident response procedures: to confirm the integrity of winpeshl.ini and to look for signs that unauthorized profits have been executed in WinRE. For practical BitLocker management guides and tools such as manage-bde and PowerShell, Microsoft documentation offers commands and examples to change protectors and deploy safe start policies.

Finally, balancing security and operational is fundamental. TPM + PIN introduces friction(PIN recovery, user support), so you have to prepare support and recovery processes (key rotation, secure storage of recovery information). Technical mitigation should be accompanied by staff awareness, physical controls and regular reviews of recovery images to quickly close similar vectors in the future.