YellowKey: The BitLocker Bypass Hidden in Windows Recovery

You lock your laptop with BitLocker, hand it to a colleague for repairs, and feel confident your data is safe. It is, right? A researcher going by Nightmare-Eclipse just published a proof-of-concept that suggests otherwise — and the method is surprisingly simple.

TL;DR

A researcher published a zero-day (YellowKey) that bypasses BitLocker on Windows 11 and Windows Server 2022/2025

The attack requires physical access and a USB stick — no passwords, no cracking, no special hardware

The vulnerability lives in the Windows Recovery Environment (WinRE), not the main OS

A component that enables the bypass exists in normal Windows installations but without the triggering behavior — raising backdoor suspicions

No CVE assigned, no patch available as of May 14, 2026

Mitigation today: switch from TPM-only to TPM+PIN, and consider disabling WinRE

What Is YellowKey?

YellowKey is a zero-day vulnerability published on May 12, 2026 by a security researcher operating under the GitHub handle Nightmare-Eclipse — the same researcher who previously released the GreenPlasma Windows privilege escalation exploit targeting the CTFMON service.

The vulnerability allows an attacker with brief physical access to a Windows 11 machine to bypass BitLocker disk encryption entirely. The attacker walks away with access to everything on the drive: files, credentials stored on disk, certificates, browser data — anything that lives on the encrypted volume.

What makes YellowKey particularly noteworthy is not just the impact, but where the vulnerability was found: inside Windows Recovery Environment (WinRE), a built-in recovery mode that ships with every Windows installation.

How the Attack Works

The attack chain is short and requires no specialized knowledge beyond following a recipe:

1. Prepare a USB drive

The attacker creates a folder at a specific path on the USB drive inside a directory called \System Volume Information\FsTx. This folder contains crafted files designed to trigger the vulnerable behavior when WinRE processes them.

2. Boot into WinRE

The attacker plugs the USB into the target machine and reboots it into the Windows Recovery Environment. This can be done by holding Shift while clicking Restart, or by interrupting the boot sequence — methods that require a few seconds of physical access.

3. Hold CTRL — get a shell

Once in WinRE, holding the CTRL key spawns an unrestricted command shell. From here, the attacker can use tools like diskpart to mount the BitLocker-protected volume and access its contents.

If a USB drive is not an option, the FsTx folder can be written directly to the EFI system partition — the small partition that stores boot files on modern machines — removing the need for external storage entirely.

The whole process, once the USB is prepared, takes under two minutes on a physical machine.

The Suspicious Component

Here is where the story gets strange.

The vulnerable component — the code inside WinRE that processes FsTx directories and replays NTFS transaction logs — is not documented anywhere publicly. It does not appear in Microsoft’s documentation, in third-party technical references, or in security research. The researcher describes it as something that “is not present anywhere (even in the internet).”

That alone would be unusual. But there is more.

The exact same component, with the exact same name, also exists in a standard Windows installation. The difference: in normal Windows, it does not expose the BitLocker bypass functionality. In WinRE, it does.

Nightmare-Eclipse states directly: “I just can’t come up with an explanation beside the fact that this was intentional.”

This is a serious claim. An undocumented component, present in a privileged recovery environment, that enables full disk encryption bypass — and whose root cause has not been independently reverse-engineered by the wider research community as of publication.

The researcher credits Microsoft’s MORSE, MSTIC, and GHOST teams for “enabling public disclosure” — which implies Microsoft was notified before the public release. Despite this, there is no CVE, no advisory, and no acknowledgment from Microsoft beyond a boilerplate statement about investigating reported issues.

Whether this is an intentional design decision, an overlooked legacy feature, or something more deliberate is currently unknown. What is known is that it works.

BitLocker Bypasses: A Recurring Problem

This is not the first time BitLocker has been bypassed through the recovery environment. CVE-2022-41099 was a remarkably similar case: an attacker with physical access could use WinRE to bypass BitLocker protections. Microsoft released a patch — but it required manually running a script to update the WinRE image on already-deployed machines. Many users never applied it.

The pattern reveals a structural problem: WinRE is a separate software image from the main Windows installation. It does not receive automatic updates the same way. Patching it requires deliberate action by administrators, and on consumer machines, this almost never happens.

BitLocker was designed to protect data from offline attacks — someone pulling your drive and reading it with another computer. WinRE sits in an awkward position: it needs enough access to repair broken systems, but that access can be turned against the very protections it is supposed to work alongside.

Who Is Affected

System	Affected
Windows 11 (all editions)	Yes
Windows Server 2022	Yes
Windows Server 2025	Yes
Windows 10	No
Systems with TPM+PIN	Likely not (unverified)
Systems with TPM-only (default)	Yes

The Windows 10 exemption is notable. The vulnerable component appears to have been introduced or changed in Windows 11. Consumer machines are particularly exposed because Windows 11 enables BitLocker with TPM-only mode by default — meaning the machine decrypts automatically on boot, without requiring a PIN. This is the configuration that YellowKey exploits.

TPM+PIN adds a second factor that must be entered before the drive unlocks. While the researcher has not released a PoC for this configuration and states it may not be affected, this remains unverified by independent researchers.

What You Can Do Today

You cannot patch this — there is no patch. But you can significantly reduce your exposure.

Switch from TPM-only to TPM+PIN

This is the most impactful change available right now. It requires a PIN to be entered at boot before BitLocker unlocks the drive.

# Check current BitLocker protectors
manage-bde -protectors -get C:

# Add a PIN to the existing TPM protector
Add-BitLockerKeyProtector -MountPoint "C:" -TpmAndPinProtector

After adding a PIN, the TPM-only protector can be removed. Verify with manage-bde -status C:.

Disable WinRE (if operationally feasible)

Disabling WinRE removes the attack surface entirely. The trade-off is losing the ability to boot into recovery mode for troubleshooting.

reagentc /disable

Re-enable with reagentc /enable when needed.

Physical Security Controls

Software mitigations are not substitutes for physical security. If an attacker has unrestricted access to a machine for two minutes, software controls become secondary.

Set a BIOS/UEFI password to prevent unauthorized boot device changes
Enable Secure Boot and verify it is enforced
Restrict boot order to internal drives only
For high-value machines: consider Kensington locks, secure rooms, and access logging

Monitor for Unexpected WinRE Boots

In managed enterprise environments, unexpected boots into WinRE should trigger an alert. This is detectable through endpoint telemetry — specifically Windows Event Log entries and MDM enrollment status changes that occur when WinRE is active.

Why a Patch Will Take Time

Even after Microsoft develops a fix, deploying it effectively will be slow. The WinRE image on already-deployed machines does not update automatically. Microsoft will need to either:

Ship a Windows Update that explicitly updates the WinRE image on disk, or
Require administrators to run a script to do so manually — as with CVE-2022-41099

For enterprise environments, this is manageable. For the hundreds of millions of consumer Windows 11 machines, many will remain unpatched for months or years, simply because most users never manually update their WinRE partition.

The physical access requirement means Microsoft will likely classify this as Medium or High severity, not Critical — reducing the urgency for an out-of-band patch. Expect the first fix to appear in a regular Patch Tuesday cycle, with WinRE update tooling arriving separately.

A realistic estimate for a complete patch with broad deployment: three to six months minimum, with full coverage across deployed machines taking much longer.

A Researcher at War With Microsoft

YellowKey does not exist in isolation. It is the latest in a series of public exploit releases by Nightmare-Eclipse, all directed at Microsoft products — and all tied to frustration with how Microsoft handles vulnerability disclosure.

The timeline tells a story:

Date	Release	Target	Status
April 2, 2026	BlueHammer (CVE-2026-33825)	Windows Defender LPE via TOCTOU race condition in threat remediation	Patched — April 2026
April 16, 2026	RedSun	Windows Defender LPE via cloud file rollback mechanism	Unpatched
May 2026	GreenPlasma	Windows CTFMON arbitrary section creation, privilege escalation	Unpatched
May 12, 2026	YellowKey	BitLocker bypass via WinRE	Unpatched

BlueHammer and RedSun both target Windows Defender — specifically, the way Defender handles detected files. BlueHammer (CVE-2026-33825) exploited a race condition in the threat remediation engine, allowing an attacker to redirect privileged file operations. Microsoft patched it in April 2026. RedSun abuses Defender’s cloud file rollback mechanism: when Defender detects a malicious file and tags it for review, the rollback process restores the file to its original location without validating the target path — a behavior an attacker can weaponize to overwrite system files and escalate privileges.

The pattern is consistent: Nightmare-Eclipse finds flaws in the tools Windows uses to protect users, then turns those tools into the attack vector. Defender becomes the delivery mechanism. The recovery environment becomes the bypass. The researcher is not discovering random bugs — they are systematically probing the trust assumptions that underpin Windows security.

This tooling has already moved beyond research. Huntress documented an in-the-wild intrusion where BlueHammer, RedSun, and an additional exploit called UnDefend were used together following a FortiGate VPN compromise as initial access. The exploits are being picked up and operationalized faster than Microsoft is patching them.

The Bigger Picture

YellowKey is not a remotely exploitable vulnerability. It requires someone to have the device in their hands. For most home users, the threat model does not change significantly — opportunistic thieves rarely come equipped with crafted USB drives.

The concern is elsewhere: targeted attacks against specific individuals or organizations. A laptop left unattended in a hotel room, a device seized at a border crossing, a machine handed in for repair. In these scenarios, brief physical access is entirely plausible — and two minutes is enough.

The backdoor question will not go away quietly. An undocumented component in a privileged recovery environment that enables full disk encryption bypass — credited to Microsoft’s own security teams before public disclosure — is not a combination that invites easy explanations. Whether the answer is legacy code, intentional design, or something else, that answer needs to come from Microsoft.

Until then: enable TPM+PIN, treat physical access to your machines as the security boundary it actually is, and watch for the patch.

LNK Shortcut Spoofing — CVE-2025-9491 — another Windows zero-day requiring minimal user interaction
BYOVD: Bring Your Own Vulnerable Driver — how attackers abuse trusted Windows components to bypass security
Windows Trusted Process Abuse — exploiting the Windows trust model from within
Windows Event Log Security Analysis — building detection capability for Windows-based attacks