YellowKey: A USB Port and a Reboot Bypass BitLocker — and Microsoft's Only Fix Is a Config Change, Not a Patch

YellowKey defeats BitLocker — the encryption defenders rely on to protect data on lost or stolen devices — through a behavioral flaw in Windows Recovery. The only available defense is a configuration change to TPM+PIN mode that most enterprise BitLocker deployments have never enabled. Every TPM-only BitLocker laptop is exposed until the organization reconfigures it.

REDMOND, WASHINGTON — On May 20, 2026, Microsoft released mitigations for YellowKey — a BitLocker security-feature-bypass zero-day tracked as CVE-2026-45585, carrying a CVSS score of 6.8. YellowKey was disclosed by the security researcher known as Chaotic Eclipse, also tracked as Nightmare-Eclipse — the same researcher behind MiniPlasma, the Windows SYSTEM-privilege-escalation zero-day The CyberSignal covered earlier this week. YellowKey abuses a behavioral trust assumption in the Windows Recovery interface, or WinRE: during the pre-boot recovery sequence, an attacker can spawn an unrestricted shell with full access to the encrypted volume, sidestepping BitLocker Device Encryption entirely. The attack requires physical access but no software installation, no existing credentials, and no network access — meaning any machine with a USB port that can be rebooted is a potential target. A proof-of-concept has been released. The flaw affects Windows 11 versions 24H2, 25H2, and 26H1 on x64, plus Windows Server 2025, including Server Core. Because no permanent patch yet exists, Microsoft's guidance is to switch BitLocker from TPM-only protector mode to TPM+PIN mode, which requires a PIN to decrypt the drive at startup.

What Happened

How YellowKey Defeats BitLocker

BitLocker is the control most organizations rely on to make a lost or stolen laptop a non-event: the drive is encrypted, so the data is assumed safe. YellowKey breaks that assumption. The vulnerability abuses a behavioral trust assumption in the Windows Recovery interface — WinRE — rather than a memory-corruption bug. During the pre-boot recovery sequence, an attacker can spawn an unrestricted shell with full access to the encrypted volume, sidestepping BitLocker Device Encryption on the system storage device entirely. The attack requires physical access to the machine, but nothing else: no software installation, no existing credentials, and no network access. As The Hacker News summarized it, any machine with a USB port that can be rebooted can be a target. A proof-of-concept has already been released.

The Researcher Behind MiniPlasma — Again

YellowKey was disclosed by Chaotic Eclipse, a researcher also tracked under the alias Nightmare-Eclipse. That name should be familiar: it is the same researcher who disclosed MiniPlasma, the cldflt.sys SYSTEM-privilege-escalation zero-day that revealed a Microsoft fix from 2020 had been silently undone. YellowKey is the second Windows zero-day from this researcher in roughly a week. Two independent, high-impact Windows security failures surfaced by one researcher inside seven days is not a coincidence of timing — it is evidence of sustained, focused independent-researcher pressure on Windows endpoint security, and it is the through-line that connects this disclosure to the MiniPlasma piece.

Affected Systems and the Mitigation Gap

YellowKey affects Windows 11 versions 24H2, 25H2, and 26H1 on x64, along with Windows Server 2025, including the Server Core installation. Microsoft has not, as of May 20, shipped a permanent patch — it has released mitigations only. The recommended mitigation is to reconfigure BitLocker on already-encrypted devices that use a TPM-only protector, switching them to TPM+PIN mode so a PIN is required at startup to decrypt the drive. That distinction — mitigation, not patch — is the heart of the defender problem. A patch arrives through the update channel and applies itself. A mitigation that is a configuration change does not: someone has to inventory the fleet, identify every TPM-only device, and push the reconfiguration. Until that work is done, the device is exposed.

Scope and Impact

The exposure is broad because TPM-only is the common case. Many enterprise BitLocker deployments — and the large majority of consumer Windows devices — use a TPM-only protector, which decrypts the drive automatically at boot with no user interaction. That convenience is exactly what YellowKey exploits. The risk concentrates in portable hardware: because the attack requires physical access, laptops and any field or travel devices are where it matters most. Several things are not yet confirmed. There is no confirmed in-the-wild exploitation — the proof-of-concept is public, but no campaign has been documented. Microsoft has not said when a permanent patch will ship. It is not publicly confirmed whether Windows 10 or earlier Windows 11 builds are affected, nor whether CISA will add CVE-2026-45585 to its Known Exploited Vulnerabilities catalog.

YellowKey lands in a month of compounding Windows endpoint-security failures. It is the second zero-day in a week from the researcher behind MiniPlasma, whose SYSTEM exploit revealed that a Microsoft patch from 2020 had silently regressed. It follows APT28's incompletely-patched Windows zero-day, where a fix closed the remote-code-execution path but left a zero-click coercion flaw open, and the Defender signature update that quarantined DigiCert root certificates worldwide. The common thread is not any single bug class — it is that Windows security controls are failing in ways that detection, configuration, and researcher scrutiny are surfacing faster than Microsoft's patch pipeline is closing them. The CyberSignal has tracked the volume side of this too: Microsoft's own MDASH AI found 16 of May's Patch Tuesday bugs while Palo Alto found 75 in a single scan.

Response and Attribution

For endpoint and device-management teams, the immediate action is a fleet-wide BitLocker protector audit: identify every device using TPM-only mode. Those devices should be switched to TPM+PIN per Microsoft's guidance — the only available defense until a permanent patch ships — using manage-bde or an Intune policy to enforce the change at scale. Laptops and portable devices should be prioritized, because physical access is the precondition for the attack and those are the devices that leave the building. For the highest-risk hardware — executive laptops, devices holding regulated data — additional pre-boot authentication layers are worth considering. This is fleet-management work, and it should be tracked as a managed remediation project with a real timeline, not assumed to happen on its own.

For SOC and incident-response teams, YellowKey changes the lost-device runbook. The attack operates pre-boot and leaves limited host-based telemetry, so detection shifts toward physical-security controls and device-loss reporting. A TPM-only BitLocker device that goes missing should now be treated as data-compromised rather than 'encrypted and safe,' and organizations should re-baseline the breach risk of any historical lost or stolen TPM-only devices. That carries compliance weight: regulated-data devices — in healthcare, finance, and government — running TPM-only BitLocker may no longer satisfy the 'encryption at rest' safe-harbor assumptions that breach-notification decisions often rest on, and counsel should be consulted. Teams should document their TPM+PIN remediation timeline, because a device lost during the remediation window is precisely the kind of event that later requires a defensible decision record. The broader reminder is that physical-access attacks remain potent even in a threat landscape dominated by remote exploitation — physical device security cannot fall off the risk register.

The CyberSignal Analysis

Signal 01 — 'Encrypted Laptop Equals Safe Laptop' No Longer Holds for TPM-Only BitLocker

The single assumption YellowKey breaks is the one most organizations have quietly built their data-loss posture around: that a BitLocker-encrypted laptop, if lost or stolen, protects its data by default. For TPM-only deployments, that is no longer true. A USB port and a reboot are enough. CISOs and risk teams should update data-loss and breach-notification risk models accordingly, and should be explicit with leadership that the fix is a configuration change, not a patch — which means it requires active, funded fleet-management work and will not resolve itself through the update channel. The honest framing for the board is that the organization's encrypted-endpoint assurance is currently conditional on a reconfiguration project that has to actually be completed.

Signal 02 — A Mitigation Is Not a Patch, and the Difference Is Operational Work

It is worth being precise about language, because the language drives the work. Microsoft has issued a mitigation for YellowKey, not a patch. A patch is delivered and applied through the update pipeline; an organization's exposure shrinks whether or not anyone is paying attention. A mitigation that consists of a configuration change shrinks exposure only for the specific devices someone actively reconfigures. Every TPM-only BitLocker device in the fleet stays exposed until it is individually moved to TPM+PIN. Treat the TPM+PIN rollout as a tracked remediation project with an owner, a device inventory, and a completion date — and do not describe YellowKey internally as 'patched,' because it is not, and that word will cause the remediation work to be deprioritized.

Signal 03 — A Design-Level Recovery-Environment Flaw Invites More Research

YellowKey is not a coding mistake in a single function; it is a behavioral trust assumption in the Windows Recovery environment — a design-level issue in how WinRE treats the pre-boot context. Design-level flaws tend to attract follow-on research, because the underlying assumption, once questioned, can usually be questioned in more than one place. It is reasonable to expect further recovery-environment findings, and worth asking whether the same WinRE trust assumption affects third-party full-disk-encryption products, not only BitLocker. Combined with the MiniPlasma regression and the broader run of Windows control failures this cycle, the prudent posture is to assume Windows endpoint security will keep generating disclosures faster than the patch cycle resolves them — and to build detection and configuration discipline that does not depend on a timely permanent fix.

Sources