A stolen Windows 11 laptop and a USB stick are enough to read a BitLocker-encrypted drive using nothing but Microsoft’s own recovery tools, and the researcher is holding back a follow-on attack that also defeats the startup PIN defenders are scrambling to enable in response.
Special thanks to Stas Lyakhov and John Loucaides for contributions
What is the vulnerability?
YellowKey is a BitLocker bypass disclosed in May 2026 by a researcher operating under the handle Chaotic Eclipse (Nightmare-Eclipse on GitHub), and it abuses behavior built into the Windows Recovery Environment to grant a fully unlocked command shell against drives that the operating system continues to treat as encrypted. The exploit primitive is the System Volume Information\FsTx directory that WinRE looks for on attached storage, because Windows will replay NTFS transaction logs found there during recovery boot, and the supplied logs delete winpeshl.ini, causing the recovery environment to fall back to spawning cmd.exe instead of the locked-down recovery UI. By the time the shell appears, the operating volume has already been transparently decrypted by the TPM, meaning the attacker inherits a fully readable filesystem with administrative tooling in hand. The researcher publicly frames this as backdoor-shaped behavior because the responsible component exists in WinRE with the exploitable functionality intact. In contrast, the equivalent component in the running Windows installation does not carry the same surface, and independent researchers, including Kevin Beaumont and Will Dormann, have publicly validated that the proof of concept behaves exactly as advertised.
Has it been patched?
At the time of disclosure, the issue was unpatched, and no CVE has been assigned. On May 19, 2025, Microsoft published recognition of the vulnerability with remediation guidance and issued CVE-2026-45585. Previously, only a generic statement about its commitment to coordinated disclosure, rather than a fix timeline, although the README credits MORSE, MSTIC, and Microsoft GHOST teams in a way that suggests at least some internal awareness before publication. Defenders should plan on the assumption that mitigation, not remediation, is the operating posture for the foreseeable future, as even after issuing a CVE, Microsoft has not issued a patch at the time of this publication.
What systems are affected?
The exploit affects Windows 11 across all builds tested by the researcher, as well as Windows Server 2022 and Windows Server 2025, while Windows 10 is reported as unaffected because the responsible WinRE component behaves differently in that codebase. The vulnerable filesystems on the attacker-supplied media include NTFS, FAT32, and exFAT, which removes any meaningful constraint on how the payload is staged.
How does the attack work, and what are the attack paths?
The attack requires physical access to the device, but the definition of physical access here is broader than most teams account for in their threat models, as the researcher demonstrated three distinct delivery paths that all lead to the same outcome. The first path is a USB stick prepared with the malicious FsTx folder inside System Volume Information, inserted into a running or powered-off target, with the attacker then forcing entry into WinRE via SHIFT+Restart followed by holding CTRL during reboot. The second path skips removable media entirely and writes the same payload directly to the EFI System Partition on the target’s internal disk, which is accessible to any user with administrative rights or any attacker with brief unattended console access through a recovery medium. The third path, and the one most relevant to evil-maid scenarios and lost-or-stolen-device assumptions, is simply to remove the storage device from the chassis, mount it on attacker-controlled hardware, write the payload to the EFI partition, and return the drive to the original system. Once any of these paths are complete and the system boots into WinRE, the NTFS log replay deletes winpeshl.ini, the recovery shell drops to cmd.exe, and the attacker now has interactive access to a volume that BitLocker still believes is protected.
The withheld PIN bypass changes the risk calculus
The public release defeats only the default TPM-only BitLocker configuration that ships on most consumer and many enterprise Windows 11 deployments, and TPM+PIN configurations are not exploitable by the published code because that mode requires user-supplied entropy at boot before the volume is unwrapped. The critical caveat defenders should not overlook is that the researcher explicitly stated they built and tested a variant that also neutralizes PIN protection and deliberately chose not to release it. That fact has two consequences worth internalizing. First, the threat model for any environment relying on TPM+PIN today should treat the PIN as raising the attacker’s cost rather than as an absolute control, because the underlying primitive is known to exist in working form in someone’s hands. Second, the timeline on which TPM+PIN remains an effective mitigation is bounded by whoever else independently rediscovers the same WinRE behavior or by the researcher’s future decision to publish, neither of which defenders control.
Recommendations for remediation
Organizations should consider the following remediation techniques:
- Disable WinRE – Turning off the Windows Recovery Environment removes the attack outright (with some caveats; see the FAQ below) by eliminating the trusted recovery shell that YellowKey hijacks. However, it also removes the safety net that users and help desks rely on, which means no more F11 boot menu, no more “Reset this PC,” no more automatic startup repair after a failed update, and no more remote walk-through recovery option when the laptop cannot make it back to IT. For organizations with mature imaging and bare-metal recovery workflows, this is a reasonable trade-off. At the same time, a small business or a BYOD-heavy environment without that infrastructure should think hard before implementing it.
- Microsoft has issued an advisory with new remediation instructions, including how to modify WinRE to remove the vulnerable functionality.
- Enable a BitLocker startup PIN – Requiring a PIN at boot is the cleanest defense against the public bypass, and the cost is exactly what it sounds like, which is users typing a code every time the machine starts or wakes. This could result in a steady stream of helpdesk calls from people who forgot the PIN, and a real headache for the IT teams that rely on overnight reboots and remote wake-up for patching, because those machines now need a human in front of them to come back online. The control may be worth the friction in any environment where lost or stolen laptops are a realistic threat, and the rollout plan should include a self-service PIN reset workflow before the first user is enrolled, because without one, the helpdesk could pay the price.
- Set a BIOS Password (a.ka. “BIOS Administrator Password”) – A BIOS or UEFI administrator password (Lenovo calls it “Supervisor Password,” Dell uses “Admin Password,” HP uses “BIOS Administrator Password”) puts the laptop’s pre-boot settings behind a lock, which prevents an attacker from changing the boot order and launching from their own USB removable media. This is not an effective mitigation for YellowKey, as the attacker is not required to change the boot order or boot from removable media. For YellowKey, an attacker must either alter the EFI partition on the current boot drive or insert a USB drive with the appropriate files. The attacker just needs to boot into WinRE, which can be done with keystrokes. Also note that a “BIOS Password” is different from a boot password (also referred to as a System or Storage password), which would require the user to enter a password before the system loads the bootloader. The NSA’s UEFI Lockdown guidance includes recommendations for these settings, such as avoiding system and storage passwords that could impact operations. Setting a “BIOS Password” is still a good security practice; however, the trade-off is that IT now owns a per-device secret that must be stored, rotated, and made available to whoever handles hardware repairs, firmware updates, and reimaging. If someone loses that password on a high-value device, it could become a paperweight (unless the vendor offers a recovery path).
- Pros and cons of BIOS password as a defensive layer – Many OEMs continue to ship firmware with documented service codes, daily master passwords derived from displayed challenge strings, or trivial CMOS reset paths that allow a determined attacker with the chassis open to clear the supervisor password in well under an hour, and Eclypsium and others have published extensively on the inconsistent quality of BIOS password implementations across the vendor landscape. More importantly for the YellowKey scenario specifically, a BIOS password does nothing to prevent the attack, including the third attack path where the attacker simply pulls the drive, modifies the EFI partition on external hardware, and returns the drive to the chassis, because at no point in that workflow does the firmware password gate the storage. BIOS passwords should not be treated as a primary control against a motivated attacker who has the device in their possession overnight.
- Monitor for the presence of “System Volume Information\FsTx” directories – Monitoring can be applied to attached USB media and on the EFI System Partition through endpoint telemetry, since the directory has no legitimate reason to appear on those volumes outside of recovery scenarios, and treat its presence as a high-confidence indicator of staging or compromise.
- Apply tamper-evident seals and physical-security controls to high-value laptops – For executives, engineers with code-signing keys, and any device storing regulated data, the realistic threat is not a movie-grade adversary but a laptop bag taken from an airport gate or a device left in a hotel room overnight. Tamper seals are cheap and let you know the device has been opened, and the companion policy controls (conditional access that requires a healthy device, remote attestation at sign-in, and short lifetimes on cached credentials and offline tokens) limit the value of anything an attacker extracts from the drive after they take physical possession, even in the case where they bypass BitLocker successfully.
Note: The above controls will likely not prevent the disk-removal path from being triggered on an unattended device.
Previous research on BitLocker bypasses
YellowKey does not arrive in a vacuum, and the value of treating it as a single news event rather than as the latest entry in a long-running research trajectory is exactly zero. The historical pattern should inform meaningful defensive decisions about BitLocker and how attackers have broken it across the last two decades. The list below presents the relevant prior works, in roughly chronological order, so that the trajectory becomes clear to anyone who has not been tracking it closely:
- Cold boot attacks (Princeton, 2008) established the foundational observation that DRAM retains contents for seconds to minutes after power loss, and that an attacker with brief physical access could chill the modules, transplant them to attacker-controlled hardware, and recover BitLocker keys directly from memory, with the research published by J. Alex Halderman and colleagues remaining the canonical reference for why memory-resident key material is a persistent class of risk rather than a solved problem.
- Windows 8 Secure Boot software bypass by Bulygin, Furtak, and Bazhaniuk (Black Hat USA 2013) – demonstrated that on platforms where the UEFI firmware in SPI flash and the EFI variable store in NVRAM were not adequately write-protected, a kernel-level attacker could corrupt a single bit of the Platform Key variable in NVRAM to force the firmware into SETUP_MODE at the next boot, which silently disables Secure Boot and allows a UEFI bootkit to install and persist beneath the operating system. The talk explicitly notes that TPM-based boot and full-disk encryption solutions, such as BitLocker, can be subverted by the same primitive because their boot-integrity measurements depend on Secure Boot being enforced in firmware rather than simply enabled in name. The talk also called out (NIST SP 800-147 BIOS Protection Guidelines and the Windows Hardware Certification UEFI Secure Boot requirements) are the same controls that still gate whether a 2026 Windows 11 laptop actually enforces the BitLocker measurements its TPM seals against.
- DMA attacks via FireWire, Thunderbolt, and ExpressCard demonstrated across a decade of research that any host controller capable of issuing direct memory access reads against the running operating system could exfiltrate BitLocker keys from a locked but powered-on machine, with Björn Ruytenberg’s Thunderspy disclosures in 2020 confirming that the underlying class of attack remained viable on shipping hardware despite years of attempted mitigation through IOMMU and kernel DMA protection settings.
- TPM bus sniffing by the Dolos Group (2021) showed that discrete TPM modules communicate the unwrapped Volume Master Key to the CPU over the LPC or SPI bus in plaintext during boot, and that a logic analyzer attached to the bus traces was sufficient to capture the key in under thirty minutes of physical access to a target laptop, with the published walkthrough establishing that TPM-only BitLocker on systems with discrete TPMs offered substantially weaker guarantees than the marketing implied.
- Stacksmashing’s Raspberry Pi Pico TPM sniffer (2024) reduced the Dolos research to a four-dollar tool that captured BitLocker keys in roughly forty-three seconds using pogo pins on debug pads, removed the soldering requirement that had previously gated the attack to skilled hardware operators, and demonstrated on modern 2023 Windows 11 laptops that the underlying weakness had not been meaningfully addressed by vendor mitigations in the intervening three years.
- CVE-2022-41099, the original WinRE BitLocker bypass, was a flaw in how the Windows Recovery Environment handled partition layout that allowed an attacker with physical access to bypass BitLocker on TPM-only configurations, with the itm4n blog publishing detailed analysis of the underlying root cause and Microsoft eventually shipping a PowerShell-script-based remediation (KB5025175) that required administrators to manually patch deployed WinRE images on every endpoint, an operational burden that resulted in widespread continued exposure long after the technical fix was available.
- CVE-2023-21563, known publicly as bitpixie, was a Windows Boot Manager bug discovered by the researcher Rairii in 2022 and fully weaponized by Thomas Lambertz at Chaos Communication Congress 38C3 in late 2024 under the talk title “Windows BitLocker: Screwed without a Screwdriver,” exploiting a PXE soft reboot path where the bootloader failed to clear the Volume Master Key from RAM after a failed boot, allowing an attacker to load a Linux environment over network boot, scan memory for the FVE-FS metadata marker followed by the 03 20 01 00 VMK signature, and extract the key in approximately five minutes with no specialized hardware. Microsoft’s mitigation, KB5025885, replaced the vulnerable Microsoft Windows Production PCA 2011 certificate with a new Windows UEFI CA 2023 certificate to prevent downgrade attacks to the vulnerable boot manager, but the rollout required Secure Boot DBX updates that many organizations have not yet completed.
- BitUnlocker (CVE-2025-48800, CVE-2025-48003, CVE-2025-48804, CVE-2025-48818) was a set of four WinRE zero-days disclosed by Microsoft’s own MORSE team in July 2025 and patched in that month’s Patch Tuesday cycle, exploiting weak validation and parsing logic in the recovery environment to allow arbitrary command execution, untrusted recovery image boot, and direct decryption of BitLocker volumes without authentication, with the vulnerabilities affecting the full supported Windows 10, Windows 11, and Windows Server 2016 through 2025 product range. BitUnlocker is the most direct ancestor of YellowKey in that both attacks weaponize the recovery environment rather than the cryptographic boundary, and the fact that two distinct WinRE-driven bypass families have surfaced within eleven months of each other is the signal worth focusing on.
- BitUnlocker conference disclosure at 39C3 (Alon Leviev, December 2025) was the public technical walkthrough of the four July 2025 WinRE CVEs by the MORSE researcher who discovered them, with the Chaos Communication Congress presentation walking attendees through the WinRE architecture, the specific attack surfaces introduced by BitLocker recovery mechanisms, the research methodology used to surface the bugs, demonstration videos of each full-chain exploit, and an assessment of Microsoft’s hardening response, making it the definitive primary-source reference for understanding why WinRE has become the dominant BitLocker attack surface.
- YellowKey (May 2026, this disclosure) continues the WinRE-as-bypass-primitive pattern, weaponizing NTFS transaction log replay against winpeshl.ini to drop the recovery shell to cmd.exe. The unreleased PIN-defeating variant claimed by the researcher should be read as a forward-looking indicator that the next entry in this list is already written and awaiting publication.
Every category of bypass that has been demonstrated remains operationally relevant on shipping Windows configurations; the mitigations are partial and operationally costly, and the trend over the past three years has been toward software-only attacks that require neither soldering nor specialized hardware. Treating BitLocker as a complete data-at-rest control without TPM+PIN, a UEFI/BIOS firmware password, tamper detection, and a working incident-response plan for stolen devices is no longer a defensible posture for any organization that has honestly reviewed the prior bypasses.
Frequently Asked Questions
No. YellowKey is a WinRE-specific bug. The primitive is NTFS transaction log replay inside the Windows Recovery Environment. Different OS, different problem.
No. Secure Boot validates what runs at boot. The attack happens after Secure Boot has already done its job. Trust chain intact. Drive unlocked anyway.
Partially. Microsoft has documented how to remove or disable WinRE in managed fleets, which closes the published attack path. It also breaks legitimate recovery workflows. However, the researcher who discovered the vulnerability published this in a blog post: “a researcher (unsure if they want to be named) told me that this binary is also present in windows update WinRE images and I think they will definitely have the same vulnerability as well. However, I’m unsure if it’s possible to trigger the controlled file deletion when windows is updating. If it’s true, then it means disabling WinRE is not a solution for the problem”
No. Those protect the login. They do not protect the disk at rest. The attacker never logs in. The attacker reads the volume directly.
Yes. Same WinRE. Same primitive. Same outcome. Consumer Windows 11 users get the worst version of this story because TPM-only is the default, and most never set a PIN.
Maybe, if you know where to look. The System Volume Information\FsTx directory on the EFI partition has no legitimate reason to exist there. Modified timestamps on winpeshl.ini in the WinRE image are another signal. However, if the attacker boots from removable USB media, these detections will not work.
Microsoft has historically treated attacks requiring physical access as out of scope for severity classification. That position has not aged well. YellowKey is exactly the kind of attack that breaks it.
Yes. Kevin Beaumont validated it. Will Dormann reverse-engineered the NTFS transaction mechanism and confirmed the root cause. The proof of concept works exactly as advertised. The handle is unusual. The bug is not.
Trust it for what it does. Distrust the marketing. BitLocker raises attacker cost. It is not a magic seal on your data. Layer it. Pair it with a PIN, a firmware password, and an incident-response plan for lost devices. That posture is defensible. Anything weaker is not.
Sources
- YellowKey GitHub Repository
- BleepingComputer: Windows BitLocker zero-day gives access to protected drives, PoC released
- MakeUseOf: New BitLocker vulnerability exposes Windows 11 users to system breach
- Neowin: Nightmare-Eclipse drops YellowKey and GreenPlasma exploits for Windows 11
- Dolos Group: From Stolen Laptop to Inside the Company Network (TPM Sniffing)
- Stacksmashing TPM Sniffing with Raspberry Pi Pico (Tom’s Hardware)
- itm4n: CVE-2022-41099 BitLocker Drive Encryption Bypass Analysis
- Compass Security: Bypassing BitLocker Encryption — Bitpixie PoC and WinPE Edition
- Microsoft Security Blog: BitUnlocker — Leveraging Windows Recovery to Extract BitLocker Secrets
