A week after Chaotic Eclipse publicly dropped the YellowKey vulnerability, Microsoft acknowledged it and published a mitigation. Not a patch, a mitigation. The distinction matters, and we will get to why.
The flaw, tracked as CVE-2026-45585 (CVSS score of 6.8), is a BitLocker security feature bypass. It affects Windows 11 versions 24H2, 25H2, and 26H1 on x64 systems, as well as Windows Server 2025 in both standard and Server Core installations.
“Microsoft is aware of a security feature bypass vulnerability in Windows publicly referred to as “YellowKey”.” reads the advisory. “The proof of concept for this vulnerability has been made public violating coordinated vulnerability best practices.”
Microsoft condemns the Chaotic Eclipse’s decision to release working exploit code without going through the standard coordinated disclosure process, the same researcher who has now disclosed five separate Windows vulnerabilities in rapid succession, including GreenPlasma, BlueHammer, RedSun, UnDefend, and MiniPlasma.
The attack is physical, for this reason, it has received a CVSS score of 6.8 rather than something higher. An attacker needs hands-on access to the target machine. With that access, they place specially crafted FsTx files on a USB drive or directly in the EFI partition, plug the drive in, reboot into the Windows Recovery Environment, and hold down CTRL. If the setup is done correctly, a shell spawns with unrestricted access to the BitLocker-protected volume. The encryption that was supposed to keep the data safe becomes irrelevant.
As Chaotic Eclipse put it in the original GitHub disclosure: if everything is done correctly, you get a shell with full access to the protected volume. No brute force, no key material needed, just the right files in the right place and a reboot.
The root of the problem is a component called the FsTx Auto Recovery Utility, autofstx.exe, which exists only inside the WinRE image and runs automatically when the recovery environment launches. The Transactional NTFS replay it triggers ends up deleting winpeshl.ini, which is what opens the door to the unrestricted shell.
Since there is no patch yet, Microsoft has outlined a manual mitigation process. It requires mounting the WinRE image on each affected device, loading the system registry hive from that mounted image, and modifying the BootExecute value under Session Manager to remove the autofstx.exe entry. After saving and unloading the registry hive, the WinRE image needs to be unmounted and committed, followed by re-establishing BitLocker trust for WinRE.
“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. It also recommends switching from TPM-only to TPM+PIN.” explained the popular cybersecurity expert Will Dormann.
“But wait!, you clever security-conscious person exclaims. If the WinRE partition is unencrypted, what stops an attacker from simply splatting back a vulnerable WinRE partition/image? You are right, you can indeed do this and you’ll get a CMD prompt when WinRE is entered. However, the modification of WinRE will cause the trust relationship between bitlocker and WinRE to fail. And as such, while you are at your handy cmd.exe prompt, you will not get an automatically-decrypted bitlocker partition.”
That second recommendation, moving from TPM-only to TPM+PIN, is arguably the more impactful of the two. TPM-only BitLocker decrypts the drive automatically at startup without requiring any user input, which is convenient but means anyone who can reboot the machine can attempt attacks like this one. Adding a PIN requirement means the drive will not decrypt without the correct input at startup, which directly blocks the YellowKey attack path.
Microsoft has provided specific guidance depending on the device state. For devices already encrypted with TPM-only protection, switching to TPM+PIN can be done through PowerShell, the command line, or the control panel. For devices not yet encrypted, administrators should enable the “Require additional authentication at startup” policy via Microsoft Intune or Group Policies and set “Configure TPM startup PIN” to require a startup PIN with TPM.
YellowKey requires physical access, which limits its real-world applicability in many enterprise scenarios. But it is not irrelevant, laptops get stolen, devices get left unattended, and in certain targeted scenarios physical access is exactly what an adversary has. BitLocker exists specifically to protect data in those situations. A bypass that works reliably against a fully patched system undermines the entire point of the protection.
The manual mitigation process is also not trivial to apply at scale. For organizations managing large fleets of devices, scripting the WinRE modification and pushing the TPM+PIN policy change through group policy or Intune is manageable, but it requires deliberate action. This is not something that fixes itself on the next Patch Tuesday without someone doing the work first.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Micorsoft)
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。