YellowKey Bypass Hits BitLocker With No Patch and a Public Exploit

On May 12, a security researcher known online as Nightmare-Eclipse released working exploit code for a Windows BitLocker bypass that needed nothing more than a prepared USB stick and physical access to the target machine. Microsoft assigned the flaw its formal identifier, CVE-2026-45585, on May 20 and immediately rated exploitation as “More Likely” given that proof-of-concept code is already circulating publicly. No patch is available, and Microsoft has not published a timeline for one.

What the company released instead is a mitigation that requires administrators to mount the Windows Recovery Environment (WinRE) image on each affected device, load a registry hive from inside that image, and manually remove a single executable entry from the system boot sequence. On a managed enterprise fleet with centralized tooling, that is a significant coordination exercise. On consumer hardware and unmanaged endpoints, it will largely not happen.

How YellowKey Opens a Locked Drive

The bypass uses a Windows file system feature called Transactional NTFS (TxF, a journaling mechanism introduced in Windows Vista in 2007 to make file operations recoverable after mid-process failures). Microsoft formally deprecated TxF years ago but never removed it from the operating system. Inside WinRE, a binary called autofstx.exe automatically processes TxF log files from a directory named FsTx on attached storage, including log files staged on USB drives, as documented in Microsoft’s Transactional NTFS technical reference.

The attack chain follows five steps:

1. Specially crafted FsTx log files are copied into a \System Volume Information\FsTx directory on a USB drive.
2. The USB drive is inserted into the target machine.
3. The system reboots into WinRE, the recovery environment present on virtually every Windows installation by default.
4. autofstx.exe processes the FsTx logs from the USB drive. Those logs delete winpeshl.ini, the configuration file that tells WinRE which application to launch at startup.
5. With winpeshl.ini removed, WinRE falls back to a plain command prompt. Holding CTRL at the right moment during boot triggers the shell. The Trusted Platform Module (TPM) chip has already released the BitLocker volume key as part of the normal trusted boot sequence, leaving the attacker with unrestricted, credential-free access to a fully decrypted drive.

No credentials are required at any point. No software installation, no network connection. The exploit works because the TPM releases its key before WinRE spawns the shell, meaning the attacker inherits a filesystem the hardware has already transparently decrypted.

Vulnerability analyst Will Dormann, of Tharros Labs, independently reproduced the attack using a USB drive and confirmed the mechanism. In his analysis, he flagged a secondary concern: TxF log files on one volume being able to modify files on a completely separate volume during WinRE startup is, in his view, a distinct vulnerability beyond the BitLocker bypass it enables. Microsoft has not commented specifically on that cross-volume behavior in its advisory language.

A Researcher Running Out of Patience

The YellowKey exploit went public on May 12, one day after Microsoft’s May Patch Tuesday cycle, timing that appears deliberate. The researcher operates under the handle Nightmare-Eclipse on GitHub and, separately, as Chaotic Eclipse. They described the flaw as “one of the most insane discoveries I ever found” and characterized it as functioning like a backdoor, noting that the vulnerable autofstx.exe component exists only inside the WinRE image and not in the standard Windows installation. Microsoft has not confirmed that characterization and says the behavior is unintentional.

YellowKey sits at the end of a longer sequence of public zero-day disclosures targeting Microsoft products from the same researcher:

• BlueHammer (CVE-2026-33825) – a Windows local privilege escalation vulnerability, patched by Microsoft in April
• RedSun – a second privilege escalation flaw, silently addressed by Microsoft with no public advisory issued
• UnDefend – a vulnerability allowing attackers to block Microsoft Defender from receiving signature updates or to disable it entirely
• GreenPlasma – a Windows CTFMON service privilege escalation exploit, released alongside YellowKey on May 12

Microsoft’s advisory described the situation plainly, stating the proof of concept was made public “violating coordinated vulnerability best practices.” The researcher has since told Microsoft in public posts that disclosures would continue “as long as you want, unless you extinguish it,” and promised a “big surprise” timed to the June Patch Tuesday release. No further detail on that promise has been published.

One detail significantly complicates the response. Nightmare-Eclipse has stated that a second proof of concept capable of bypassing TPM+PIN protection already exists and is being deliberately withheld. TPM+PIN is precisely the stronger of Microsoft’s two recommended mitigations for CVE-2026-45585.

Affected Windows Versions

Microsoft’s formal advisory covers five configurations. Windows 10 is absent because its WinRE setup differs in ways that prevent the same attack path from completing.

The CVSS (Common Vulnerability Scoring System) score of 6.8 places the flaw in the medium-severity band numerically, driven by the physical-access requirement. Microsoft’s own exploitation probability rating, “More Likely,” signals a different calculus, one shaped by the fact that working exploit code is publicly available and does not require specialized skills to use. Independent researchers have also flagged Windows Server 2022 as potentially vulnerable via the same WinRE recovery path, though Microsoft has not addressed that in its current advisory.

What Microsoft’s Mitigation Requires

The Registry Fix

The first mitigation targets autofstx.exe directly, removing it from the WinRE boot sequence so it cannot process FsTx logs during recovery. Per Microsoft’s official CVE-2026-45585 mitigation guidance, administrators must mount the WinRE image on each device, load the system registry hive from inside the mounted image, then locate the Session Manager’s BootExecute value and remove the autofstx.exe entry from its REG_MULTI_SZ data. Microsoft updated the advisory on May 21 to include an automation script that can execute these steps, which simplifies deployment for environments using Microsoft Intune or Group Policy.

The critical limitation is that WinRE does not update automatically through standard Windows Update cycles. The recovery environment is a separate software partition from the main operating system, and pushing a change into it requires deliberate action on every affected device. Organizations without centralized device management face the same manual, machine-by-machine process the advisory describes, with no automated delivery mechanism to fall back on.

Switching to TPM+PIN

Microsoft’s second option addresses the threat at a different layer. Devices currently using TPM-only BitLocker can be switched to TPM+PIN mode using PowerShell, the command line, or the Control Panel. Under TPM+PIN, the drive cannot decrypt at startup without a user-entered PIN, which means an attacker who triggers a WinRE shell still cannot read the volume without knowing that code. Microsoft’s guidance on configuring this mode is available in the BitLocker deployment and administration documentation.

For devices not yet encrypted, the guidance calls for enabling the “Require additional authentication at startup” policy through Intune or Group Policy and configuring the TPM startup PIN option to required. For those already encrypted in TPM-only mode, the switch to TPM+PIN can be completed without first decrypting the drive. Microsoft describes this as the more effective of the two options for blocking the current attack path.

The caveat that changes the calculus: Nightmare-Eclipse has publicly stated that a proof of concept bypassing TPM+PIN protection is being withheld and has not yet been released. If that claim is accurate and the researcher follows through, the second mitigation loses much of its protective value. Microsoft has not responded to that specific claim in its advisory language, and the withheld proof of concept remains unverified by independent researchers as of publication.

A Pattern Microsoft Has Seen Before

YellowKey is not the first BitLocker bypass to exploit the recovery environment. CVE-2022-41099, disclosed in November 2022, let attackers with physical access use WinRE to reach a disk encryption-protected volume through a different mechanism. The structural problem was identical: the fix required updating the WinRE image on already-deployed machines, and WinRE does not update automatically.

Microsoft shipped a patch for CVE-2022-41099’s WinRE bypass that required administrators to run a PowerShell script on each affected machine to push the correction into the recovery partition. The fix was not automatic. Many machines, particularly consumer devices and endpoints outside managed enterprise environments, never received the update at all. Security researchers who tracked that vulnerability noted adoption was poor, and the underlying delivery problem was never resolved.

The same structural constraint applies now. WinRE is a separate software image from the main Windows installation, and it does not receive corrections through normal cumulative patch delivery. A future Patch Tuesday update is expected to bake the current fix directly into WinRE images for new installations. But for the hundreds of millions of existing Windows 11 machines already deployed in the field, broad remediation will require the same type of deliberate, device-by-device action that produced inadequate adoption rates the last time this pattern played out, a dynamic Eclypsium’s researchers highlighted in their analysis of the YellowKey WinRE attack path.

The Case of the Unattended Laptop

BitLocker’s core promise is data protection for devices that leave their owner’s hands: a laptop taken from a hotel room, seized at a border crossing, handed to a repair technician, or stolen from an unattended bag. These are exactly the scenarios where physical access is available, credentials are not, and network connectivity is irrelevant. The exploit breaks that protection for any affected device configured in TPM-only mode, which is the default for many enterprise BitLocker deployments precisely because it allows a silent, PIN-free startup experience.

The exposed devices are not low-stakes. Executives, field engineers, legal and finance teams, and anyone whose laptop regularly leaves a managed office environment carry exactly the kind of sensitive data that disk encryption exists to protect. Many enterprise BitLocker deployments default to TPM-only mode because requiring a startup PIN creates friction for users and additional recovery overhead for IT teams. That convenience now has a measurable cost.

Organizations with unmanaged or consumer Windows 11 endpoints face a broader problem still. Even administrators who apply the registry fix to their managed fleet are operating with a mitigation, not a patch, and a mitigation that must reach every individual device before the exploit does. The gap between those two timelines is the actual exposure window.

The next scheduled opportunity for a permanent fix is the June Patch Tuesday release, the same cycle in which Nightmare-Eclipse has promised an unnamed “big surprise.” If Microsoft ships a full WinRE-baked update in June, the manual mitigation becomes a bridge rather than a long-term control. If it does not, every affected machine with a USB port stays a viable target through the summer with exploit code that is already published and requires no specialized skills to run.