Microsoft has started rolling out mitigations for YellowKey, a Windows zero-day that can let an attacker with physical access get around BitLocker protection on a machine’s storage drive. The flaw is tracked as CVE-2026-45585 and carries a CVSS score of 6.8.
The issue matters because it does not rely on remote compromise or a phishing email. According to Microsoft’s advisory, an attacker needs hands-on access to the target system and a USB drive carrying the publicly released YellowKey exploit code. From there, rebooting into recovery mode can be enough to push the system into exposing the underlying contents of the disk.
Instead of loading the normal Windows Recovery Environment, the exploit can drop the attacker into a shell. That bypasses the protection BitLocker is supposed to provide for data at rest, which is why the disclosure has drawn attention from defenders watching for endpoint theft, lab access, and other physical-security risks.
What Microsoft says the mitigation does
In its advisory, Microsoft describes the problem plainly: a successful attacker could bypass BitLocker Device Encryption on the system storage device and access encrypted data with physical access to the machine.
Will Dormann, senior principal vulnerability analyst at Tharros Labs, said the mitigation effectively blocks the FsTx Auto Recovery utility, known as autofstx.exe, from automatically starting when the WinRE image begins to load. That utility sits at the center of the attack path.
Microsoft’s guidance also walks defenders through a fairly involved remediation process. It includes mounting the WinRE image on each affected device, opening the registry hive for that image, removing autofstx.exe from the mounted hive, remounting the updated image, and then restoring BitLocker trust for WinRE.
The company also recommends adding a PIN to BitLocker.
Why recovery mode became the weak point
At the heart of YellowKey is an unusual abuse of Windows recovery behavior. Dormann said last week that the exploit uses a USB-based trigger when entering Windows Recovery, with FsTx helping delete the winpeshl.ini file that helps control WinRE’s behavior.
According to that explanation, the exploit includes an FsTx directory on the USB drive. When Windows replays the transactional NTFS data, it can remove winpeshl.ini from the System32 folder. The result is a command prompt instead of the normal recovery interface, and that prompt appears with BitLocker no longer standing in the way.
Dormann also pointed to something broader than the BitLocker bypass itself. He said the buried issue may be that a System Volume InformationFsTx directory on one volume can alter another volume during replay, which he described as sounding like a vulnerability in its own right.
A PIN helps, but questions remain
Microsoft’s recommendation to use a PIN with BitLocker is sensible, but the disclosure has an added wrinkle. Chaotic Eclipse, the researcher who released YellowKey along with several other Windows zero-days, says the exploit also works on systems where TPM protection has been paired with a PIN.
That claim raises the stakes for anyone relying on physical-device assumptions alone. TPM-based security is often treated as a strong baseline for consumer and enterprise Windows machines, but this case is a reminder that recovery tooling, boot behavior, and encryption trust chains can still create openings if one piece is misused.
For organizations, the practical takeaway is simple: encrypted endpoints still need physical-security controls, and recovery partitions deserve the same scrutiny as the rest of the operating system image. For individual users, the episode is another argument for keeping BitLocker configured carefully rather than assuming the default setup covers every scenario.
Why this bug has security teams paying attention
YellowKey is being watched not just because it bypasses BitLocker, but because it involves a public proof of concept, a local physical attack path, and Windows recovery internals. That combination tends to make exploitation more accessible than a deeply technical kernel flaw or a remote chain that needs a long setup process.
The fix also follows a familiar pattern for Windows defenders: once a recovery-related bypass appears in the wild, the safest response is often to lock down the boot and recovery chain as tightly as possible, then verify that the encryption trust relationship still holds after remediation.
Microsoft’s mitigations are now available, but the disclosure suggests the attack surface around WinRE and transactional NTFS is worth a closer look. For anyone managing Windows devices at scale, this is one of those issues where the recovery environment is no longer just a support tool — it is part of the security boundary.