YellowKey CVE-2026-45585: BitLocker Bypass With a USB Drive and a Reboot
Physical access to a Windows machine is not supposed to mean access to its encrypted data. BitLocker exists precisely to protect against this — even if an attacker steals your laptop or walks up to an unattended workstation, full-disk encryption should be an insurmountable barrier. YellowKey eliminates that guarantee. Microsoft released mitigations for YellowKey, a publicly disclosed BitLocker bypass tracked as CVE-2026-45585, with a CVSS score of 6.8. Microsoft noted that the proof of concept for this vulnerability has been made public, violating coordinated vulnerability best practices.
The exploit requires no credentials, no network access, and no advanced technical skill — just a USB drive, a target Windows machine, and a reboot. This blog explains exactly how YellowKey works, which systems are affected, and the mandatory mitigation steps every Windows administrator must implement today.
How YellowKey Works: The FsTx File Attack Chain
The Three-Step Exploit Chain
YellowKey was disclosed by a security researcher named Chaotic Eclipse (aka Nightmare-Eclipse). It essentially allows 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.
The exploit chain requires three sequential actions anyone can execute:
- Create a malicious USB — place specially crafted
FsTxfiles on a USB drive or EFI partition - Insert and reboot — plug into any affected Windows machine and trigger WinRE boot
- CTRL-key shell activation — hold CTRL during WinRE launch to spawn an unrestricted shell
"If you did everything properly, a shell will spawn with unrestricted access to the BitLocker protected volume," the researcher noted in the public GitHub post. Successful exploitation could permit an attacker with physical access to sidestep the BitLocker Device Encryption feature and gain access to encrypted data.
Why FsTx Files Defeat BitLocker
The vulnerability exploits the Transactional NTFS auto-recovery utility — autofstx.exe — which runs automatically when WinRE launches. The mitigation specifically prevents the FsTx Auto Recovery Utility from automatically starting when the WinRE image launches. With this change, the Transactional NTFS replaying that deletes winpeshl.ini no longer happens.
The winpeshl.ini deletion is the key mechanism — the FsTx replay deletes this file, which controls the WinRE shell environment, allowing the attacker's CTRL-key input to spawn an unrestricted system shell instead of the normal recovery interface.
Table: CVE-2026-45585 YellowKey — Attack Profile
| Attribute | Detail |
|---|---|
| CVE ID | CVE-2026-45585 |
| CVSS Score | 6.8 (Medium — requires physical access) |
| Attack Vector | Physical (USB drive + local access) |
| Privileges Required | None |
| User Interaction | None after USB insertion |
| PoC Public | Yes — GitHub post by Chaotic Eclipse |
| Patch Available | Mitigation only (no full patch yet) |
| BitLocker Modes Affected | TPM-only protector |
Affected Systems and Deployment Scope
Which Windows Versions Are Vulnerable
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.
The Windows Server 2025 inclusion is particularly significant — this is not a consumer-only vulnerability. Enterprise data center environments and hybrid server deployments running Server 2025 face the same physical-access BitLocker bypass risk as endpoint devices.
Important: The CVSS score of 6.8 reflects the physical access requirement — but in corporate environments, physical access scenarios include stolen devices, malicious insiders, supply chain hardware tampering, and unattended workstations. Do not underestimate this vulnerability because of its medium CVSS rating.
The Microsoft Mitigation: What You Must Do Right Now
Mandatory WinRE Modification Steps
The following mitigations have been outlined by Microsoft: 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 Session Manager's BootExecute REG_MULTI_SZ value; save and unload the Registry hive; unmount and commit the updated WinRE image; and reestablish BitLocker trust for WinRE.
The TPM+PIN Upgrade: Your Most Effective Defense
Microsoft emphasized that users can be safeguarded against exploitation by configuring BitLocker on already encrypted devices by switching from "TPM-only" 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 blocking 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."
Table: YellowKey Mitigation Priority Matrix
| Action | Target | Priority | Method |
|---|---|---|---|
| Switch BitLocker to TPM+PIN | All BitLocker-protected endpoints | Immediate | PowerShell / Intune / Group Policy |
| Remove autofstx.exe from WinRE | All affected Windows versions | Immediate | Microsoft advisory steps |
| Reestablish BitLocker trust for WinRE | All affected Windows versions | Immediate | Post-WinRE modification |
| Enable startup PIN requirement | Unencrypted devices | High | Intune / Group Policy |
| Physical access controls review | Server 2025 environments | High | Policy and infrastructure |
| Deploy official patch when released | All systems | As available | Windows Update |
Key Takeaways
- Switch all BitLocker deployments from TPM-only to TPM+PIN immediately — this single change blocks YellowKey attacks regardless of WinRE modification status
- Apply the WinRE autofstx.exe removal via Microsoft's advisory steps on all affected Windows 11 and Server 2025 systems
- Treat Windows Server 2025 as equally exposed — this is not a consumer endpoint-only vulnerability
- A public PoC exists — the attack is reproducible by any threat actor with physical access and the GitHub post
- Review physical access controls — BitLocker protects against physical attacks; ensure your physical security posture matches your digital encryption posture
- Do not rely on CVSS 6.8 to deprioritize — stolen laptops, malicious insiders, and unattended workstations all represent viable physical access scenarios for this exploit
Conclusion
YellowKey is a reminder that encryption is only as strong as the protection of the key management environment. BitLocker's TPM-only mode trusts the system's own boot process — and YellowKey corrupts that trust through WinRE manipulation. Switching to TPM+PIN eliminates the attack vector entirely by requiring a human-entered secret that no USB drive can provide. Apply the WinRE mitigation, deploy TPM+PIN across your fleet via Intune, and assess your physical access controls for high-risk device categories. Do not wait for the full patch — the mitigation available today is sufficient to block the published exploit chain.
Frequently Asked Questions
Q: What is YellowKey CVE-2026-45585 and how does it bypass BitLocker? A: YellowKey is a BitLocker security feature bypass that exploits the Windows Recovery Environment (WinRE) by placing specially crafted FsTx files on a USB drive. When the USB is inserted and the system reboots into WinRE, the FsTx auto-recovery utility manipulates the WinRE shell environment, allowing the attacker to spawn an unrestricted shell with full access to the BitLocker-protected volume.
Q: Which Windows versions are affected by CVE-2026-45585? A: The vulnerability affects Windows 11 versions 24H2, 25H2, and 26H1 for x64-based systems, as well as Windows Server 2025 and Windows Server 2025 Server Core installations. Earlier Windows versions and ARM-based systems are not listed as affected in Microsoft's current advisory.
Q: What is the most effective single mitigation for YellowKey? A: Switching BitLocker from TPM-only mode to TPM+PIN mode is the most effective mitigation. This requires a PIN at startup to decrypt the drive, which no physical USB attack can provide — effectively blocking the YellowKey exploit chain regardless of WinRE modification status. This can be deployed at scale via Microsoft Intune or Group Policy.
Q: Is a public proof-of-concept available for this exploit? A: Yes — security researcher Chaotic Eclipse published a detailed proof-of-concept on GitHub before Microsoft released mitigations, violating standard coordinated disclosure best practices. This makes the exploit immediately reproducible by any threat actor with physical access to an affected device, significantly elevating the urgency of the TPM+PIN migration.
Q: Does this vulnerability affect encrypted drives or only unencrypted ones? A: It specifically targets BitLocker-protected (encrypted) drives — that is the point of the attack. The FsTx exploit manipulates WinRE to gain unrestricted shell access to volumes that are already encrypted with BitLocker's TPM-only protector. Drives using TPM+PIN are not affected because they require a PIN that the attacker cannot provide.
Enjoyed this article?
Subscribe for more cybersecurity insights.