YellowKey is unpatched and your travel laptops are exposed today

Your travel laptops are the problem this week. If you ship default Windows 11 with TPM-only BitLocker, a public proof-of-concept released on May 12 lets anyone with five minutes of physical access drop into a command prompt on the unlocked OS volume. No password, no PIN, no recovery key. A USB stick and a reboot.

The bug is called YellowKey, and it does not have a CVE. Microsoft has not patched it. The researcher published it the day after May Patch Tuesday after MSRC closed the original report over an unmet “submit a demo video” requirement. The PoC is on GitHub, and Kevin Beaumont, KevTheHermit, and Will Dormann reproduced it on fully patched Windows 11 within 24 hours.

The operational picture for the next four weeks: TPM+PIN on exposed devices, this week if you can.

What it actually does

The mechanism is worth a paragraph because it shapes the mitigation. The PoC abuses NTFS Transactional File System log replay inside the Windows Recovery Environment. A crafted \System Volume Information\FsTx folder on an attached drive gets processed by WinRE on boot, and the replay deletes winpeshl.ini from inside the running WinRE image (Cyber Unit’s writeup names the file). That file is what tells WinRE to launch the graphical recovery UI instead of a bare cmd.exe. With it gone, the next boot lands in a command prompt.

The BitLocker part is the boring part, and that is what makes it dangerous. WinRE is Microsoft-signed and measured, so on a default TPM-only configuration, the TPM releases the volume master key before the shell-selection step. By the time the attacker’s cmd.exe spawns, the C: drive is already mounted and decrypted. The exploit does not break BitLocker. It walks around it through a recovery path the TPM trusts.

Windows 11, Windows Server 2022, and Windows Server 2025 are vulnerable per the researcher’s own README. Windows 10 is not. Microsoft has only said it is investigating (SecurityWeek). No CVE, no KB, no KEV entry. The PoC is one-shot and leaves no telemetry, so do not expect KEV to update even if this is being used.

TPM+PIN is the play

Pre-boot authentication breaks the dependency the PoC relies on. If the TPM is gated on a startup PIN, the volume master key is never released to WinRE on a cold boot, so the recovery shell has nothing to land on. A community tester confirmed the PoC stalls at the pre-boot prompt on a TPM+PIN machine. That is the mitigation.

The GPO is at Computer Configuration → Administrative Templates → Windows Components → BitLocker Drive Encryption → Operating System Drives → Require additional authentication at startup, with Configure TPM startup PIN set to Require startup PIN with TPM. Per-machine, the manage-bde -protectors -add C: -tpmandpin syntax does the same thing. Turn on Allow enhanced PINs for startup in the same policy node if you want alphanumeric PINs, but validate on each chassis model first. Some legacy BIOS implementations cannot render alphanumeric input pre-boot and will reject enhanced PINs outright.

The honest tax: the first two weeks will be a help-desk PIN-reset spike. The reset flow is recovery key from AD or Entra or Intune, boot Windows, run manage-bde -changepin C:. Plan for it.

Three populations should not get a startup PIN. Kiosks and shared workstations, because nobody owns the credential. Service-account machines that boot unattended after reboot. And headless servers (Hyper-V hosts, file servers, branch DCs) where a pre-boot prompt strands the box waiting for a console operator who is not there. Scope the GPO to your laptop and shared-office OUs, not server OUs. Make sure recovery-key escrow to AD DS or Entra ID is on before the PIN policy lands, and know that Intune does not natively support silent BitLocker enrollment when a startup PIN is required, which complicates zero-touch provisioning.

The caveat that keeps this open

This is the sentence to carry into the change board meeting. In the post that accompanied the PoC, the researcher wrote that TPM+PIN “does not solve the problem: the flaw remains exploitable no matter what” and claimed a second variant exists that works against TPM+PIN environments. The quote is consistent across The Hacker News and SecurityWeek. That variant has not been released, reproduced, or independently described.

Treat it the way you would treat any one-source claim from an anonymous researcher who is already annoyed with the vendor. Plausible, not proven. Deploy TPM+PIN because it definitively stops the public PoC today. Do not tell your CISO it is a permanent fix. Watch for either a Microsoft patch or a researcher follow-up.

When TPM+PIN is genuinely infeasible

For fleets where pre-boot PIN rollout cannot happen in the available window, reagentc /disable as administrator removes WinRE from the boot path and cuts the FsTx replay vector at the source. You lose Startup Repair, Reset This PC from recovery, and any self-service flow that depends on WinRE. If your actual recovery story is Autopilot reset or re-imaging, the regression is minor. If users rely on push-button recovery, it is real.

This is also the lever Microsoft used for KB5025885, the BlackLotus / CVE-2023-24932 remediation, which required a WinRE update and a Secure Boot boot-manager revision bump. The playbook for boot-chain attacks runs through WinRE servicing. Whatever Microsoft ships for YellowKey will likely look similar, which means the June 2026 Secure Boot 2011 CA expiry matters here too. Devices stuck on the 2011 CA will stop receiving boot-chain updates entirely. If a YellowKey fix lands through that channel, those devices will not get it. That is a separate workstream, but it compounds on the same fleet.

A BIOS supervisor password with USB removed from the boot order is a useful layer on top, named alongside TPM+PIN as a recommended mitigation by Beaumont in The Hacker News coverage and supported by Microsoft’s own BitLocker countermeasures docs. The caveat: BIOS supervisor passwords are bypassable on a lot of consumer-grade chassis (MDSec, March 2026). On enterprise hardware with audit logging and intrusion sensors, the BIOS password is a meaningful layer. On miscellaneous consumer gear, it is a thin one.

What gets prioritized

YellowKey requires physical access and a reboot. A desktop behind a badge reader and a server in a locked rack are a different risk category from anything that leaves the building. The defensible posture is risk-stratified rollout, not fleet-wide TPM+PIN by Friday:

• Travel laptops, field-tech machines, and branch endpoints: TPM+PIN this week. These are the devices the PoC was designed against.
• Kiosks and semi-public devices: reagentc /disable and a BIOS password. A startup PIN does not fit the use case.
• Desktops in access-controlled offices: wait for the patch. Do not burn the helpdesk on devices that never leave the room.
• Servers: do not put a startup PIN on them. Physical security and reagentc /disable are the levers.

Detection is the weakest layer, and it is worth being honest about that. A one-shot physical exploit that leaves the OS untouched is not what endpoint telemetry is built to catch. Unexpected recovery-key demands in the Microsoft-Windows-BitLocker-API/Management event log, unscheduled WinRE entries in Defender for Endpoint timelines, and MDM check-in gaps on devices known to be in transit are worth alerting on, but they are lagging indicators at best and useless if the device is offline during the event.

The framing to bring to the change board: this is not a fire, it is a window. The PoC needs physical access, so a hotel-room laptop is the realistic threat model, not a phishing payload at scale. TPM+PIN on the exposed tier this week, the rest of the fleet on the patch when it lands, and an explicit note in the board minutes that the researcher’s second-variant claim is unresolved. June Patch Tuesday is the next obvious window for a Microsoft response. Plan as if it slips.

Sources

• Windows BitLocker zero-day gives access to protected drives, PoC released — BleepingComputer, May 2026
• Windows BitLocker zero-day — YellowKey WinRE bypass — Cyber Unit, May 2026
• YellowKey researcher repository and README — Nightmare-Eclipse, May 2026
• Researcher drops YellowKey, GreenPlasma Windows zero-days — SecurityWeek, May 2026
• YellowKey issue #2 — TPM+PIN reproduction — Nightmare-Eclipse, May 2026
• manage-bde protectors reference — Microsoft Learn
• Configure BitLocker — Microsoft Learn
• Windows zero-days expose BitLocker — The Hacker News, May 2026
• KB5025885 — Windows boot manager revocations for CVE-2023-24932 — Microsoft Support
• Windows Secure Boot certificate expiration and CA updates — Microsoft Support
• BitLocker countermeasures — Microsoft Learn
• Disabling security features in a locked BIOS — MDSec, March 2026