A USB stick. A reboot. Full drive access. That is the entire attack chain for CVE-2026-45585, the BitLocker bypass that Chaotic Eclipse dropped as a zero-day in May 2026. Microsoft has acknowledged it, given it a name in the industry press ("YellowKey"), and published mitigations, but at the time of writing there is no patch.
The vulnerability went public roughly a week before Microsoft responded. The researcher, who also operates under the handle Nightmare-Eclipse, published a working proof-of-concept along with a statement that frustration with Microsoft's bug-reporting process pushed them to disclose without coordination. The PoC is in the wild, which means anyone with a download and a few minutes of physical access to a target machine can replay the attack.
Microsoft issued CVE-2026-45585 on or around 19 May 2026, scored it 6.8 on the CVSS scale, and tagged it "Exploitation More Likely" in its severity guidance. What did not arrive with the advisory was a binary fix. Instead, Microsoft published configuration changes that disrupt the attack chain and promised a full patch at an unspecified later date. Both The Hacker News and BleepingComputer have covered the disclosure timeline, with the latter being the original break of the zero-day story.
So far there is no confirmed exploitation in the wild, but that distinction matters less than it sounds. The PoC is public, the technique is repeatable, and the target population is enormous. Treat the "no active exploitation" line as a clock, not a reassurance.
The bug lives in the Windows Recovery Environment. An attacker prepares specially crafted files with the FsTx extension and drops them either onto a USB drive or directly onto the EFI partition of the target device. They then reboot the machine into WinRE. Holding the CTRL key during the recovery flow triggers a shell that should not be accessible in that context, and from inside that shell the BitLocker-protected volume is fully readable and writable.
There is no key cracking. No recovery password is harvested. No PIN is guessed. The bypass routes around the cryptographic boundary entirely by abusing trust the recovery environment extends to a vulnerable component (autofstx.exe) that processes the FsTx file payload. No malware needs to be installed on the host first, no network connection is required, and the attacker does not need any existing account on the system. Help Net Security has a clear write-up of the chain if you want a second reference on the technical sequence.
The kicker: BitLocker running in its default TPM-only protector mode does not stop any of this. The TPM happily unseals the volume key during a normal boot path that the attacker has subverted, because from the firmware's perspective nothing looks wrong.
The advisory lists Windows 11 versions 24H2, 25H2, and 26H1 on x64, along with Windows Server 2025 in both standard and Server Core installations. That is the modern Windows estate. If you are running a recent corporate fleet image, you are almost certainly in scope.
Think about where this lands in the real world. Laptops left in hotel rooms during conferences. Devices stolen from cars or checked luggage. Hot-desks in shared offices where a machine sits unattended for ten minutes at lunch. Co-working spaces. Repair shops. Customs inspections. Anywhere a machine with a USB port can be rebooted by someone who is not you, this attack is viable. That is the kind of physical attack surface that most threat models still under-weight, and it is the surface YellowKey targets directly.
CVSS knocks the score down because the attack vector is local rather than network. From a scoring methodology standpoint that is correct. From an operational standpoint it is misleading, and this is one of those cases where you have to read past the number. If you have ever wondered what CVSS actually measures, the gap between "local access required" and "irrelevant to my business" is exactly where it shows up.
The threat model for a corporate laptop in 2026 includes physical access. Devices travel. Devices get lost. Devices sit in conference cloakrooms and hotel safes and the back seat of taxis. A full-disk bypass that needs only a USB stick and a reboot is, in practical terms, a critical issue for any organisation with a mobile workforce. When you are deciding which CVEs to patch first, do not let the 6.8 lull you into queueing this behind a 7.5 RCE on an internal service that is already segmented off.
SecurityWeek notes the same dissonance in its coverage: the base score does not capture how exposed encrypted endpoints actually are when physical custody changes hands.
The headline mitigation is switching BitLocker from TPM-only to TPM+PIN. With a pre-boot PIN in place, the WinRE shell that YellowKey unlocks cannot decrypt the volume, because the TPM will not release the key without the PIN being entered first. The attack chain still triggers, but it lands the attacker in a shell with nothing useful to read.
You can apply this through PowerShell, the manage-bde command line, or the BitLocker control panel for individual machines. For fleet rollout, Group Policy supports enforcing TPM+PIN organisation-wide under the BitLocker Drive Encryption settings. Be deliberate about communication. End users who have never typed a pre-boot PIN before will call the help desk on day one, and you want enrolment flows, PIN complexity guidance, and recovery procedures sorted before you flip the policy.
The alternative mitigation Microsoft has published is to remove autofstx.exe from the mounted WinRE image hive and then re-establish BitLocker's trust relationship with the modified WinRE. This is more invasive, but it neutralises the vulnerable component directly rather than working around it. For fleets where rolling out TPM+PIN is operationally painful in the short term, the autofstx removal path is worth piloting.
If a device in your estate goes missing between now and the patch, treat the encrypted-at-rest assumption as broken. Wipe credentials, rotate tokens cached on the device, and reset session material. When the device returns, look for evidence of physical tampering: EFI partition modifications, unexpected files, recent WinRE boots in the event log. None of these are conclusive on their own, but together they shape a defensible incident response narrative.
It stops the attack as currently described. The WinRE shell that the FsTx payload spawns runs in a context that depends on the TPM unsealing the BitLocker volume key automatically. Adding a PIN means the TPM will not release the key without user input, so the shell exists but cannot read the encrypted volume. This is a real cryptographic gate, not an obstacle that the published PoC can sidestep. Treat it as a proper mitigation, but keep watching for technique variants.
Higher than most teams assume. Cleaners, contractors, after-hours staff, and anyone who tailgates through reception all have opportunity windows that exceed the few minutes this attack requires. If the laptop is in TPM-only mode and a USB port is reachable, the encryption is no longer providing the protection on the data sheet. Locked drawers, cable locks, and CCTV help, but the durable fix is the configuration change. Physical security controls reduce probability; TPM+PIN reduces impact.
Probably not, given what is already public. A working PoC is circulating, the technique is documented across multiple outlets, and Microsoft has not committed to a patch date. Every day spent waiting is a day where any lost or stolen device in your fleet is recoverable by anyone with basic tooling. If TPM+PIN is genuinely blocked by user-experience constraints, pilot the autofstx removal route on a subset of high-risk endpoints, starting with travelling staff and executives.
