YellowKey: The Unpatched BitLocker Bypass in Windows Recovery and the SMB Lost-Laptop Playbook

On May 12, 2026, a researcher publishing under the alias Nightmare-Eclipse dropped a working proof-of-concept on GitHub named YellowKey. The exploit bypasses BitLocker drive encryption on Windows 11 and Windows Server 2022/2025 using a prepared USB drive and two minutes at the keyboard. No CVE number has been assigned. Microsoft has issued no patch and no official advisory beyond a statement that it is "actively investigating the validity and potential applicability of these claims." Kevin Beaumont and independent researcher KevTheHermit both confirmed the exploit functions against recent Windows 11 builds, according to SecurityWeek's coverage. The attack requires physical access - but physical access happens: laptops get stolen from cars, hotel rooms get entered during conferences, and supply chain vendors get unsupervised time with corporate hardware.

The default BitLocker configuration on Windows 11 - TPM-only, no PIN - is vulnerable to the published PoC. That default is what most SMB endpoints ship with unless an administrator has explicitly changed it via Group Policy. TPM+PIN blocks the public proof-of-concept, and the researcher has declined to publish the TPM+PIN variant, stating that "what's out there is already bad enough." Microsoft's silence on a remediation timeline means there is no patch to wait for. The only action available right now is configuration hardening, and for organizations that rely on BitLocker to protect data on mobile devices, that hardening needs to happen before the next lost laptop.

How YellowKey bypasses BitLocker in under two minutes

The attack exploits a component that exists inside the Windows Recovery Environment (WinRE) image but is not present in the standard Windows installation. According to the Hive Security technical writeup, this component processes directories named FsTx inside the System Volume Information folder and replays NTFS transaction logs. The key detail is architectural: that behavior exists only inside WinRE. The same component is present in a normal Windows installation but does not expose the bypass.

The attack sequence is straightforward. An attacker creates a FsTx folder with crafted files on a USB drive - the PoC repository contains the required structure. They insert the USB, reboot into Windows Recovery Environment by holding Shift during restart or interrupting the boot sequence, then hold the CTRL key until an unrestricted command shell spawns. From that shell, diskpart mounts the BitLocker-protected volume. Everything on the drive - files, cached credentials, certificates, browser profiles, SSH keys, cloud tokens stored in config files - is readable without the BitLocker recovery key or any user-supplied PIN.

There is also a keyless variant. The FsTx folder can be written directly to the EFI system partition instead of an external USB drive. That path requires brief write access to the partition but eliminates the need to carry external media. The full exploit chain, including identifying the EFI partition and writing the folder structure, is documented in the public PoC repository. According to Blackfort Technology's analysis, the process takes under two minutes on a physical machine.

The researcher describes the undocumented WinRE component as potentially "a backdoor intentionally planted into BitLocker," citing the fact that the behavior exists nowhere on the public internet in documented form and exists exclusively inside the recovery image. Whether that characterization is accurate is not confirmed. What is confirmed is that the component enables the bypass and Microsoft has not disputed that the bypass works.

Who is actually exposed

The vulnerability affects Windows 11 across all editions, Windows Server 2022, and Windows Server 2025. Windows 10 is not affected. The key variable is the BitLocker protector configuration:

• TPM-only (Windows 11 default): Vulnerable to the published PoC. The machine boots silently without any user input, which is convenient for end users and also means no second factor stands between WinRE and the encrypted volume.
• TPM + PIN: Blocks the public PoC. The researcher has stated a TPM+PIN variant exists but has withheld it. The threat level here is lower than TPM-only but is not zero.
• TPM + Startup Key: Also blocks the public PoC, but startup keys on USB drives introduce their own physical-access risks and add operational complexity that most SMBs cannot sustain.

The SMB exposure is not abstract. A 200-person company with 150 Windows 11 laptops on default configuration has 150 machines where a two-minute USB attack yields full disk access. The people most likely to carry those laptops - sales, field technicians, executives - are also most likely to lose them at airports, leave them in rental cars, or hand them to hotel staff for "assistance." The number that matters is not devices stolen annually; it is devices that return to corporate possession having been briefly unaccompanied.

GreenPlasma: the SYSTEM escalation dropped alongside YellowKey

Nightmare-Eclipse published a second unpatched exploit simultaneously, named GreenPlasma. It exploits the Windows CTFMON component to create an arbitrary memory section object in any SYSTEM-writable directory, enabling local privilege escalation to SYSTEM-level. Like YellowKey, it carries no CVE and has no patch. The researcher published a partial PoC stripped of the components needed to land a full SYSTEM shell.

The two are not chained in the published PoC. YellowKey dumps disk contents from a machine at rest; GreenPlasma is a post-boot local escalation for a logged-in user. The fact that both arrived simultaneously, both unpatched, from the same researcher suggests this is not the full extent of the findings. Treat the combined disclosure as a signal to audit the entire endpoint hardening baseline, not just the two published techniques.

The SMB hardening playbook

There are five steps, and they are ordered by impact. Do not wait for all five before starting the first.

1. Audit which endpoints are TPM-only right now

Before you can remediate, you need to know your exposure. Run the following PowerShell on each managed endpoint, or adapt it for remote fleet auditing via WMI or your endpoint management platform:

# Identify BitLocker protector type on the system drive
# TPM-only (KeyProtectorType = "Tpm") with no TpmPin = vulnerable to YellowKey PoC

$volume = Get-BitLockerVolume -MountPoint "C:" -ErrorAction SilentlyContinue
if (-not $volume) {
    Write-Host "BitLocker not enabled on C:"
    exit
}

$types = $volume.KeyProtector.KeyProtectorType
$hasTpm    = $types -contains "Tpm"
$hasTpmPin = $types -contains "TpmPin"

if ($hasTpm -and -not $hasTpmPin) {
    Write-Host "[VULNERABLE] TPM-only. YellowKey public PoC can bypass this config."
    Write-Host "  Protectors: $($types -join ', ')"
} elseif ($hasTpmPin) {
    Write-Host "[PROTECTED]  TPM+PIN is set. Public PoC is blocked."
    Write-Host "  Protectors: $($types -join ', ')"
} else {
    Write-Host "[REVIEW]     Non-standard protectors: $($types -join ', ')"
}

# To bulk-audit domain endpoints, iterate Get-ADComputer and query via Invoke-Command:
# Invoke-Command -ComputerName (Get-ADComputer -Filter *).Name -ScriptBlock { ... }

Machines that return [VULNERABLE] are your immediate remediation priority. For most SMBs that have not explicitly enforced TPM+PIN, expect the majority of Windows 11 endpoints to be in that category.

2. Enforce TPM+PIN via Group Policy

The Group Policy setting that matters: Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives > "Require additional authentication at startup." Enable it, then under the TPM startup PIN option select "Require startup PIN with TPM." Without this GPO applied first, users cannot set a PIN even manually.

After the GPO is applied, you have two paths to add the PIN protector to existing encrypted drives. The clean path is to prompt users to set their own PIN via the BitLocker management wizard on next login. The enforced path is to push the pin addition via endpoint management, which requires a mechanism to distribute the PIN securely - awkward at scale. For SMBs with under 100 endpoints, the cleanest operational approach is a help desk ticket per machine with a user-chosen PIN confirmed verbally, logged in your ITSM.

Some Windows 11 24H2+ builds require an additional registry key to allow PIN-at-startup when Secure Boot is enforced. Check Microsoft's Configure BitLocker documentation for your build before deploying.

3. Disable WinRE where recovery access is not operationally required

If your organization manages endpoints via Autopilot, Intune, or SCCM, and your IT recovery workflow does not require WinRE, disabling the recovery partition is a direct mitigation. One command, elevated PowerShell or admin command prompt:

reagentc /disable

This removes the WinRE boot option. The trade-off is real: if the OS drive fails to boot, the recovery environment is no longer available. For organizations with disk image rollback capability through MDM or SCCM reimaging, this trade-off is acceptable. For organizations that rely on WinRE to recover failed updates or corrupted user profiles, it is not. Evaluate operationally, do not apply universally.

4. Harden the boot environment

The YellowKey attack chain begins with booting into WinRE. Two controls raise the bar before the attacker reaches the exploit:

• UEFI/BIOS password: Prevents an attacker from changing the boot order to a USB device without knowing the firmware password. Set this on every managed endpoint. The password should be stored in your ITSM, not on a sticky note on the chassis.
• Disable USB boot in firmware: Blocks the USB-based variant of the attack. An attacker who cannot boot from the USB drive cannot trigger the exploit from external media, though the EFI-partition variant remains if the attacker has brief write access while the OS is running.

Enforce Secure Boot if not already enabled. It does not block YellowKey directly, but it is part of the boot-chain integrity baseline Microsoft recommends and reduces the surface for other pre-boot tamper classes.

5. Update physical security policy to reflect the threat model

This step has no PowerShell command, but it is the one most likely to prevent the actual incident. YellowKey requires two minutes of physical access to a target machine. The laptop that gets left in a rental car overnight, checked at a hotel business center, or handed to a conference AV crew provides that window. Practical policy changes that cost nothing to implement:

• Full-disk encryption check on all mobile devices is now a conditional-access enforcement point, not a documentation checkbox.
• Any device reported lost or out of control for more than 30 minutes gets a remote wipe initiated immediately, not at the end of the week when IT "gets a chance to look at it."
• Hardware security keys and credentials cached in browser profiles are treated as compromised if the device was unaccompanied. Rotate them on return.

What Microsoft has said, and why it is not enough

Microsoft's official position is that the company is "actively investigating the validity and potential applicability of these claims." That statement does not confirm a patch timeline, a CVE assignment, or even a formal acknowledgement that the bypass works. Kevin Beaumont and KevTheHermit have confirmed it does. The PoC is public. The investigation timeline is Microsoft's, not yours.

The absence of a CVE creates a practical problem for patch programs that triage by KEV catalog or CVSS score. There is nothing to scan for, no KEV due date to anchor a ticket. This is a configuration deficiency, not a software flaw waiting for a hotfix. Add "BitLocker TPM+PIN enforced on all Windows 11 endpoints" to your CIS or NIST baseline and close it there. TPM+PIN is the only reliable defense against the published exploit today, and it is available without waiting for a vendor patch.