Disclaimer: I've spent the last two weeks writing about NGINX Rift, Fragnasia, and various Linux kernel catastrophes. Linux has been hogging all the vulnerability spotlight. So when a Windows BitLocker bypass drops this week, I'm covering it not because I suddenly became a Windows security expert, but because the universe has a sense of fairness and apparently Linux needed company in the "fundamentally broken" department. Consider this your Linux sysadmin's attempt to explain Windows disasters.

A researcher calling themselves Nightmare-Eclipse just published YellowKey, a working proof-of-concept exploit that bypasses BitLocker encryption on Windows 11 and Windows Server 2022/2025 with nothing but a USB stick containing a single folder. No zero-day kit required. No fancy tools. Just a crafted filesystem transaction log that deletes a configuration file, and suddenly an attacker with physical access gets a command prompt with the encrypted drive fully unlocked.

There is no patch. There is no CVE. Microsoft hasn't publicly acknowledged it. And the researcher who found it believes it looks deliberately placed, not accidentally broken.

What is BitLocker and why this matters

BitLocker is Windows' built-in full-disk encryption. When active, everything on the drive is mathematically scrambled and unreadable without a key. That key is held by a Trusted Platform Module (TPM) — a security chip soldered to the motherboard.

In the most common configuration on consumer Windows 11 machines (called TPM-only mode), the TPM automatically hands over the decryption key at boot without prompting for a password. The drive unlocks silently. This is convenient but comes with a threat model: if someone gets unsupervised physical access to the machine, they can access everything.

BitLocker was designed specifically for this scenario. It was supposed to be the answer to "what if my laptop is stolen or briefly accessed by someone else?" For years, that promise held. YellowKey breaks it.

How the attack works: deleting one config file

Windows has a recovery environment called WinRE (Windows Recovery Environment). When the system is too broken to boot normally, you can press Shift+Restart to get a blue recovery interface with diagnostic tools. Because WinRE needs to repair the disk, the TPM cooperates and unlocks the BitLocker volume during recovery boots.

A configuration file called winpeshl.ini controls what program launches when WinRE starts. Normally it's the recovery interface. If winpeshl.ini is missing, WinRE falls back to a command prompt with the drive already unlocked.

YellowKey deletes winpeshl.ini.

The mechanism is buried in Windows plumbing:

1. Transactional NTFS (TxF): A deprecated-but-never-removed Windows feature from 2007 that makes filesystem operations "transactional" — like database commits. Changes are logged before applying.
2. autofstx.exe in WinRE: A binary inside the Windows Recovery Environment that processes these transaction logs from a folder called FsTx.
3. The bug: autofstx.exe doesn't limit its operations to the drive it came from. It applies transactions from external drives to internal drives too.

A USB stick with crafted transaction logs can therefore modify files on the system's internal recovery partition — a completely different volume.

The attack, step by step

This is real. Will Dormann at Tharros Labs independently reproduced it and confirmed it works.

Preparation (on an attacker's machine):

1. Create the directory structure: System Volume Information\FsTx\
2. Place the transaction log files (provided in the YellowKey GitHub repo) in that folder
3. Copy this folder to a USB drive

Attack (on the target machine with BitLocker active):

1. Plug the USB drive into the machine
2. Hold Shift and click Restart to boot into WinRE
3. The moment the machine starts restarting, stop holding Shift and hold CTRL
4. A command prompt appears
5. The BitLocker-protected drive is already unlocked and accessible
6. You can now copy files, install malware, create backdoor accounts, etc.

The whole thing takes a few minutes. Total time an attacker needs physical access: about 5 minutes if they know what they're doing.

The conspiracy angle: The researcher notes that autofstx.exe exists in normal Windows installations but doesn't have this cross-volume behavior. Only inside the WinRE image is it vulnerable. Windows 10 isn't affected. Windows 11 and Server versions are. The deliberate nature of the distinction — the capability is there, just activated in recovery mode — has led both independent researchers and security analysts to ask: was this put there intentionally?

Nightmare-Eclipse believes yes. Kevin Beaumont (widely respected security researcher) publicly agrees. The Register reported sources saying it's impossible to verify from public information. That's where it stands: the capability is documented, the intent is not.

Additional complexity: BitLocker with PIN doesn't help (maybe)

Most recommendations when hearing about this say "just add a BitLocker PIN." The TPM won't release the key without the correct PIN at boot.

The researcher claims YellowKey works against TPM+PIN setups too and says a proof-of-concept exists but is being withheld as of publication date. This is not independently verified yet. Only the TPM-only variant has been tested by third parties.

Check which mode you're in:

manage-bde -status

If it says "TPM" under Key Protectors, you're vulnerable to the confirmed variant. If it says "TPM and PIN," the researcher's claim applies, but it's unverified.

There's another BitLocker bypass this week

As if one BitLocker catastrophe wasn't enough, a French security firm called Intrinsec published a separate working exploit called BitUnlocker (CVE-2025-48804). It's built on a vulnerability Microsoft patched in July 2025 but never properly revoked the signing certificate for.

Old, vulnerable boot managers are still signed with the old PCA 2011 certificate, and Secure Boot accepts them. BitUnlocker reaches a decrypted drive in under 5 minutes on fully patched Windows 11.

So: two completely independent BitLocker bypasses published this week through different attack paths, both granting full access to encrypted drives.

Mitigations (ranked by effectiveness)

1. Physical security (only foolproof option)

Don't let machines out of your sight unsupervised. Period. This covers every variant including the EFI partition method.

2. BIOS/UEFI password + disable USB boot

Set a firmware password and disable external boot devices. The USB variant requires the machine to boot from external media.

Go into BIOS/UEFI settings (F2, F10, Del, or F12 during startup, depending on manufacturer), set a supervisor password, and disable USB boot.

3. Add a BitLocker PIN

# As administrator
manage-bde -protectors -add C: -tpm -pin

This works against the confirmed TPM-only variant. Whether it stops the unpublished TPM+PIN variant is unknown.

4. Disable WinRE (maybe)

# Disable recovery environment
reagentc /disable

⚠️ Caveat: The May 14 update noted that autofstx.exe also appears in Windows Update WinRE images. Disabling WinRE might not be permanent if Windows Update reinstalls it.

5. Don't use BitLocker TPM-only on sensitive machines

TPM-only was built for convenience, not security against physical access. Use TPM+PIN or full password encryption instead.

Who is Nightmare-Eclipse and why should you care

The person behind YellowKey also published RedSun and UnDefend in April, both zero-days. They've also been working on BlueHammer (Windows Defender flaw, assigned CVE-2026-33825 and patched). Every previous disclosure has gone into active exploitation within days or weeks.

The researcher has promised a "big surprise" for June 2026 Patch Tuesday. Every promise so far has been delivered.

The Register reported rumors that this person is a former Microsoft employee. This is unconfirmed and unverifiable from public sources. Whether that's true or not, the pattern suggests this is coordinated, escalating disclosure tied to a grievance against Microsoft.

The hard questions

Is BitLocker broken? Not entirely. It works if:

• You have TPM+PIN configured
• You physically secure the machine
• You disable WinRE
• You disable USB boot

But it is demonstrably less secure than the marketing implies, especially on default configurations where it's active but transparent to the user.

Why hasn't Microsoft patched this? Unknown. MSRC (Microsoft Security Response Center) is aware. There's no public statement. The vulnerability affects active product versions (Windows 11, Server 2022, Server 2025). A patch exists somewhere in Microsoft's labs; whether they release it, when, and how loudly they announce it is TBD.

Should I panic? Depends on your threat model:

• If your laptop might be stolen: add a PIN, disable USB boot, or use full-disk encryption with a password
• If your machines are physically secured in a datacenter: less urgent, but still patch when available
• If you're running WinServer 2022/2025 in the cloud: You're probably not affected (VMs don't have TPMs to unlock), but get confirmation from your cloud provider

Bottom line

BitLocker is compromised on default configurations. Two separate BitLocker bypasses were published this week by independent researchers. One works with nothing but a USB folder. The other exploits an old signing certificate Microsoft never revoked. Both reach the decrypted drive in minutes with physical access.

Microsoft hasn't patched. Microsoft hasn't publicly acknowledged it. The researcher who found YellowKey has escalated disclosures repeatedly over two months and promised worse for June.

Add a PIN to BitLocker. Disable USB boot. Physically secure your machines. And wait for Microsoft to decide whether they're going to fix this or hope nobody notices.

This is not theoretical. Will Dormann at Tharros Labs confirmed it works. Kevin Beaumont confirmed it works. The code is public. Assume it will be weaponized if it hasn't been already.

For the record: I'm a Linux guy. I'm much more comfortable with dm-crypt and kernel modules than I am with TPM transaction logs and recovery environments. But when someone publishes proof-of-concept code for a fundamental encryption bypass on machines running 200+ million Windows installations, it's worth understanding what broke and why, regardless of whether it's your OS.

And yes, after two weeks of Linux vulnerabilities, it's almost comforting to learn that Windows isn't secure either. Misery loves company.