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.
| Aspect | BitUnlocker (Microsoft STORM) | YellowKey (Nightmare-Eclipse) |
|---|---|---|
| Discoverer | Microsoft STORM team | Independent researcher Nightmare-Eclipse |
| Disclosed | Black Hat USA 2025 / DEF CON 33 (Aug 2025) | GitHub / public disclosure (May 2026) |
| Patched | July 2025 Patch Tuesday (4 CVEs) | No patch as of writing |
| Attack vector | Multi-step BCD + PBR manipulation | Single USB, CTRL key hold during WinRE boot |
| Affected | Windows 10/11 + Server | Windows 11 + Server 2022/2025 only |
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
- Create a folder
FsTxon a USB stick atUSB:\System Volume Information\FsTx - Plug the USB into a BitLocker-protected Windows 11 machine
- Hold SHIFT and click Restart (boots into WinRE)
- As the system reboots, release SHIFT and press and hold CTRL
- 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=1Once 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:
| Observation | Implication |
|---|---|
The FailRelock debug flag exists only in WinRE, not in the normal Windows component with the same filename | A deliberate testing facility was shipped in production |
| The exact same binary name exists in normal Windows without the bypass functionality | This is not a generic debugging leftover — it was specifically placed in WinRE |
| Only Windows 11+ affected (not Windows 10) | The code was introduced in the new WinRE image for Windows 11 |
| No documentation, no configuration tool, no public reference | Standard debug/test flags are usually documented internally — this one appears to have been intentionally concealed |
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
| Dimension | BitUnlocker | YellowKey |
|---|---|---|
| Technical sophistication | High — multi-step BCD, PBR, and XML manipulation | Low — simple USB + key combination |
| Time to execute | ~10-30 minutes | ~2 minutes |
| Persistence | Can permanently decrypt the volume | Session-based access only |
| CVE | CVE-2025-48800, 48003, 48804, 48818 | No CVE assigned |
| Patch status | Fixed July 2025 | Unpatched |
| Windows 10 affected | Yes | No |
| Backdoor suspicion | No (standard vulnerability disclosure) | Yes (researcher claims intentional) |
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.
| Protector mode | Resistance to YellowKey | User experience |
|---|---|---|
| TPM only | Broken | Best (no password) |
| TPM + PIN | Resistant | Good (PIN at boot) |
| TPM + USB key | Resistant | Poor (need USB) |
| Password only | Resistant | Poor (password each boot) |
| Recovery key | N/A | Emergency use only |
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:
- Enable TPM + PIN protector — Run
manage-bde -protectors -add C: -TPMAndPINfrom an elevated command prompt - Set BIOS/UEFI password — Prevents boot device selection tampering
- Disable external boot — Configure UEFI to only boot from internal storage
- Disable WinRE — (Not recommended for production, but as a last resort)
reagentc /disable
Long-term (Organizational Policy)
| Control | Implementation |
|---|---|
| BitLocker Group Policy | Enforce Require additional authentication at startup → Configure TPM startup PIN: Require startup PIN with TPM |
| Secure Boot + DBX | Ensure Secure Boot is enabled with the latest revocation list (dbx) |
| Windows Defender System Guard | Enable System Guard Secure Launch (SMM protection) |
| Update WinRE | Apply latest WinRE servicing stack updates (KB5034231 and later) |
| BitLocker Network Unlock | For domain-joined desktops, use Network Unlock to avoid TPM-only pitfalls |
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:
- TPM-only BitLocker on Windows 11 is effectively decorative against a determined physical attacker
- Laptop theft now equals data breach unless TPM+PIN or stronger protections are enabled
- 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
| Date | Event |
|---|---|
| 2024-2025 | Microsoft STORM team researches WinRE attack surfaces |
| 2025-07 | Microsoft patches BitUnlocker CVEs in July Patch Tuesday |
| 2025-08 | STORM presents BitUnlocker at Black Hat USA & DEF CON 33 |
| 2026-05-12 | Nightmare-Eclipse publishes YellowKey on GitHub |
| 2026-05-13 | The Register confirms YellowKey with security experts |
| 2026-05-13 | Community reverse engineering confirms FailRelock debug flag mechanism |
| 2026-05-14 | This article published — no official patch from Microsoft |
The Bigger Picture: A Pattern of WinRE Trust Failures
YellowKey is not an isolated incident. Looking at the broader landscape:
| Vulnerability | Year | Component | Impact |
|---|---|---|---|
| CVE-2024-20666 | 2024 | Secure Boot / BitLocker | Security feature bypass |
| CVE-2025-48800 | 2025 | WinRE / tttracer | BitLocker bypass via offline scanning |
| CVE-2025-48003 | 2025 | WinRE / SetupPlatform | BitLocker bypass via hotkey |
| CVE-2025-48804 | 2025 | WinRE / Boot.sdi | Boot verification bypass |
| CVE-2025-48818 | 2025 | WinRE / PBR | Complete decryption of BitLocker volume |
| YellowKey | 2026 | WinRE / FsTx debug flag | One-key BitLocker bypass |
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