Before we get into the exploit itself, a quick intro on who's behind it. YellowKey was disclosed by a researcher known as Nightmare-Eclipse (or Chaotic-Eclipse), who had originally tried to go through the process of reporting vulnerabilities to Microsoft's MSRC bug bounty program. Turns out, he didn't get paid for his efforts so instead of playing nice he decided to publish two Windows Defender zero days as revenge (BlueHammer and RedSun) and now he's back with YellowKey, a BitLocker bypass he describes as 'one of the most insane discoveries I ever found, almost feels like backdoor'.
YellowKey targets TPM-only BitLocker on Windows 11 and Windows Server 2022/2025 (Windows 10 is currently unaffected). The vulnerability lives inside the Windows Recovery Environment (WinRE), specifically in a binary called autofstx.exe. This component scans attached storage for NTFS transaction log data under System Volume Information\FsTx and replays whatever it finds. The problem is that the replay can modify content on a completely different volume than the logs came from.
To exploit it, you prepare a USB stick with specially crafted FsTx files, plug it into the target machine with BitLocker enabled, and reboot. When WinRE starts, autofstx.exe picks up the FsTx directory on the USB drive and replays it, deleting the winpeshl.ini file from the recovery partition. That file is what normally tells WinRE to launch the recovery UI. Without it, WinRE falls back to spawning a raw cmd.exe prompt instead. You need to hold down the CTRL key during boot to trigger the specific code path, and if it lands correctly, you get a command prompt with direct read access to the BitLocker protected system volume. This works because by the time WinRE is reached, the TPM has already released the encryption key through the normal boot chain and nothing about the chain of trust has been violated. The bug is in how trivially that access can be redirected into a free shell.
It's worth noting that the exploit doesn't work on every device. Microsoft has a mechanism called Trusted WIM Boot that stores a hash of the WinRE image and verifies it during recovery boot. If the FsTx replay modifies the WinRE image, the hash check should fail and the volume stays locked. Whether this triggers depends on whether the device's BitLocker metadata actually contains the WIM hash, which apparently isn't the case on a significant number of consumer laptops.
The researcher has stated that the bug is also exploitable on devices configured with TPM+PIN, and has a working PoC for it but he's not releasing it. This claim is interesting because, by design, TPM+PIN requires the user to enter a PIN before the TPM releases the encryption key. A powered-off laptop booted by an attacker shouldn't have the encrypted volume mounted by the time WinRE is reached. Until Microsoft explains how WinRE accesses protected volumes or the researcher releases the second PoC, it's a claim worth watching but not yet confirmed.
Previous methods of bypassing Windows disk encryption required prolonged physical access and physical tampering with the hardware, think opening up the laptop and sniffing the TPM pins (this video is a good example). YellowKey changes that equation entirely. With nothing more than a USB stick and a key combination during reboot, anyone with brief physical access can bypass the encryption. No password. No recovery key.
There's also the question of what this component is doing inside WinRE in the first place. The vulnerable binary lives only in the recovery image, the same component exists in a normal Windows install, but without the specific functionality that produces the bypass. That kind of asymmetry is not the shape of a normal bug. Whether it's a forgotten debug pathway or something more intentional, Microsoft has not offered an explanation yet.
Microsoft has not yet shipped an official patch. The researcher has been openly critical of Microsoft's handling of vulnerability disclosures, including silently patching RedSun without issuing any advisory. Given he's already disclosed six vulnerabilities in six weeks, it's clear he's not stopping anytime soon.