YellowKey & BitUnlocker: Inside the Windows BitLocker Bypass That Looks Like a Backdoor

YellowKey and BitUnlocker: Two independent discoveries of the same class of vulnerability — WinRE’s auto-unlock trust boundary being exploited to bypass BitLocker full-volume encryption. One was found by an external researcher who calls it a backdoor; the other was found by Microsoft’s own STORM team and patched as four CVEs.

The Two Sides of the Same Coin

In the span of less than a year, two teams approaching from completely different directions landed on the same terrifying conclusion: BitLocker’s default TPM-only protection can be silently bypassed through the Windows Recovery Environment (WinRE), giving anyone with physical access full command-line access to an “encrypted” drive.

The unsettling part? Neither requires breaking AES. Neither requires brute-forcing your recovery key. Both simply walk through a door that was left open.

BitUnlocker: Microsoft Finding Its Own Flaws

Microsoft’s Security Testing and Offensive Research at Microsoft (STORM) team presented BitUnlocker at Black Hat USA 2025 and DEF CON 33. It uncovered four distinct attack vectors in WinRE, all patched with July 2025 Patch Tuesday:

CVE-2025-48804: SDI File Injection

WinRE’s boot process uses a Boot.sdi (System Deployment Image) file. Researchers found they could append a malicious Windows image to the legitimate Boot.sdi. Since WinRE doesn’t properly validate the WIM after the SDI header, the untrusted image boots as if it were trusted, inheriting WinRE’s auto-unlock privileges for BitLocker volumes.

CVE-2025-48800: tttracer.exe Abuse

WinRE’s “Offline Scanning” scheduled operation runs antivirus scans against encrypted volumes. The utility tttracer.exe (Time Travel Debugger), a legitimate Microsoft-signed binary, can be used to proxy-execute cmd.exe without triggering BitLocker’s re-lock mechanism. The command prompt inherits WinRE’s special permissions to access encrypted volumes.

CVE-2025-48003: SetupPlatform.exe Hotkey

SetupPlatform.exe — a component that remains in the trusted app registry after Windows upgrades — registers a Shift+F10 hotkey that launches a command prompt. Crucially, this doesn’t trigger a re-lock of BitLocker volumes. An attacker who can influence WinRE’s ReAgent.xml configuration can exploit this for persistent access.

CVE-2025-48818: Full Decryption via PBR

The crown jewel. By manipulating Boot Configuration Data (BCD) stores, attackers can redirect WinRE’s Push Button Reset (PBR) flow. The ResetSession.xml file includes a DecryptVolume directive. By placing a malicious BCD store on the unprotected Recovery volume, the attacker tricks PBR into decrypting the BitLocker-protected OS volume entirely.

All four CVEs were assigned a CVSS v3.1 score of 6.8 (Medium) — due to the requirement for physical access. But as any security practitioner knows, “physical access required” is cold comfort when a laptop is stolen from a coffee shop.

YellowKey: The One That Broke the Internet

In May 2026, researcher Nightmare-Eclipse dropped YellowKey on GitHub with a description that immediately went viral:

“One of the most insane discoveries I ever found, almost feels like backdoor but what do you know, maybe I’m just insane.”

The Exploit in 5 Steps

1. Create a folder FsTx on a USB stick at USB:\System Volume Information\FsTx
2. Plug the USB into a BitLocker-protected Windows 11 machine
3. Hold SHIFT and click Restart (boots into WinRE)
4. As the system reboots, release SHIFT and press and hold CTRL
5. A command shell spawns with full, unrestricted access to the BitLocker-encrypted volume

That’s it. No complex payload. No cryptographic breaking. No recovery key. Just a USB stick and the right timing of key presses.

Why It Works

The component responsible for this behavior exists only inside WinRE images. It checks for a flag called FailRelock in a configuration file (RecoverySimulation.ini). When set, after WinRE unlocks the BitLocker drive during the recovery process, it simply never relocks it.

The RecoverySimulation.ini file on the USB triggers “test mode” for WinRE’s recovery tools:

[Simulation]
Active=Yes
FailRelock=1

Once test mode is active, WinRE’s cmd.exe inherits the unlocked state — and reads and writes to the encrypted volume as if BitLocker didn’t exist.

Nightmare-Eclipse demonstrated this affects Windows 11 and Server 2022/2025 but not Windows 10, suggesting the vulnerable code was introduced in the WinRE version shipped with Windows 11.

Backdoor or Bug? The Evidence

What makes YellowKey particularly disturbing is the pattern of evidence that suggests intentionality:

The Register quoted security experts who said it’s “impossible to verify” whether this is an intentional backdoor based on available information. But the circumstantial evidence is, at minimum, suspicious enough to demand a detailed explanation from Microsoft.

Comparison: YellowKey vs BitUnlocker

The two are complementary: BitUnlocker demonstrates that even Microsoft’s own security team found systemic trust issues in WinRE, while YellowKey suggests the problem may be worse than anyone imagined — perhaps by design.

Why TPM-Only Is Not Enough

BitLocker’s default configuration on modern Windows devices uses TPM-only protection. The TPM validates boot integrity (PCR registers) and releases the encryption key automatically if the system boots normally. This provides seamless user experience — no typing passwords at every boot.

But it also means: anyone who can boot the device can get the key.

The YellowKey exploit works because TPM-only auto-unlock trusts WinRE implicitly. When you add a PIN, the TPM won’t release the key without the PIN — even in WinRE. This breaks the attack chain.

Defense in Depth: Mitigation Strategies

Immediate (No Reboot Required)

For YellowKey specifically, until Microsoft releases a patch:

1. Enable TPM + PIN protector — Run manage-bde -protectors -add C: -TPMAndPIN from an elevated command prompt
2. Set BIOS/UEFI password — Prevents boot device selection tampering
3. Disable external boot — Configure UEFI to only boot from internal storage
4. Disable WinRE — (Not recommended for production, but as a last resort) reagentc /disable

Long-term (Organizational Policy)

Detection

There is no reliable log-based detection for YellowKey, since the exploit operates entirely within WinRE before the OS boots. However:

• Pre-boot behavior monitoring: Devices that boot to WinRE unexpectedly should trigger investigation
• Physical access audits: Track devices that have been out of sight
• USB boot logs: UEFI firmware may log boot device selections

What This Means for the BitLocker Threat Model

The traditional threat model for BitLocker was:

Attacker with physical access: Protected unless they have the recovery key or can brute-force TPM + PIN.

The updated threat model after YellowKey is:

Attacker with physical access to Windows 11+: Full compromise in ~2 minutes using a USB stick and a held key.

This is a paradigm shift. It means:

1. TPM-only BitLocker on Windows 11 is effectively decorative against a determined physical attacker
2. Laptop theft now equals data breach unless TPM+PIN or stronger protections are enabled
3. Enterprise deployments relying on default BitLocker config are exposed — the “check the box and forget it” era is over

The most disturbing part is the asymmetry: the attacker needs only a USB stick and two minutes of physical access. The defender needs to roll out policy changes, educate users, and ensure every device has TPM+PIN enabled.

Disclosure Timeline

The Bigger Picture: A Pattern of WinRE Trust Failures

YellowKey is not an isolated incident. Looking at the broader landscape:

The WinRE/WinPE attack surface has repeatedly proven to be the weakest link in BitLocker’s chain. Microsoft’s architectural decision to trust WinRE implicitly for auto-unlock — without cryptographic attestation of what WinRE is doing — creates a fundamental design tension: how do you allow recovery without allowing recovery abuse?

So far, every answer has failed.

Conclusion

YellowKey and BitUnlocker represent the same fundamental problem: WinRE’s privileged access to BitLocker volumes cannot be adequately secured through software policy alone when an attacker with physical access can manipulate the recovery environment itself.

If you’re responsible for Windows security in your organization:

Audit your BitLocker configuration today. If TPM+PIN is not enforced, assume your encrypted data is accessible to anyone with a screwdriver and a USB stick.

Train your users. A stolen laptop is no longer just a hardware loss — with YellowKey, it’s a guaranteed data breach if TPM-only is in use.

Watch for Microsoft’s response. If patch Tuesday passes without addressing YellowKey, the “backdoor” theory becomes significantly harder to dismiss.

References

• YellowKey GitHub Repository: https://github.com/Nightmare-Eclipse/YellowKey
• The Register Coverage: https://www.theregister.com/2026/05/13/disgruntled-researcher-releases-two-more-microsoft-zero-days/
• Microsoft BitUnlocker Blog Post: https://techcommunity.microsoft.com/blog/microsoft-security-blog/bitunlocker-leveraging-windows-recovery-to-extract-bitlocker-secrets/4442806
• CVE-2025-48800 (MSRC): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-48800
• CVE-2025-48003 (MSRC): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-48003
• CVE-2025-48804 (MSRC): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-48804
• CVE-2025-48818 (MSRC): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-48818
• Saltt Tech Analysis: https://www.saltt.tech/insights/bitunlocker-a-deep-technical-analysis-of-a-full-volume-encryption-bypass

Infographics

Figure 1: YellowKey exploit flow — USB insertion → WinRE boot → CTRL held → unrestricted shell on encrypted volume