The Exposure: The YellowKey BitLocker bypass is a publicly released BitLocker bypass PoC affecting Windows 11 and Windows Server 2022/2025 systems under reported recovery conditions. Public reporting states Windows 10 is not affected.
The Exploit Vector: An attacker with physical access reportedly uses crafted FsTx metadata stored in \System Volume Information\FsTx through a USB device or EFI partition path.
The Mechanism: The YellowKey BitLocker bypass abuses Transactional NTFS behavior in Windows Recovery Environment (WinRE), allowing deletion of winpeshl.ini and exposing a command shell with access to the decrypted drive.
The “Backdoor” Suspicion: Claims describing the issue as a BitLocker encryption backdoor originate from the researcher and have not been confirmed by Microsoft or independent public reporting.
Validation: Researchers, including Will Dormann and Kevin Beaumont, reportedly reproduced the YellowKey BitLocker bypass on updated Windows 11 systems.
The YellowKey BitLocker bypass has raised concerns about how TPM-based BitLocker protection behaves during Windows Recovery Environment (WinRE) operations. On May 12, 2026, a researcher using the names “Chaotic Eclipse” and “Nightmare-Eclipse” publicly released a proof-of-concept (PoC) exploit targeting BitLocker-protected systems running Windows 11 and Windows Server 2022/2025 under specific recovery conditions.
Public reporting states that the exploit chain abuses behavior inside the Windows Recovery Environment (WinRE), a recovery platform designed to help repair systems that fail to boot normally. During legitimate recovery workflows, the Trusted Platform Module (TPM) may automatically provide BitLocker decryption material if the hardware state appears trusted, allowing recovery utilities to access the protected drive.
According to technical analysis shared by researchers and reproduced by independent security practitioners, the YellowKey proof-of-concept uses crafted Transactional NTFS (TxF) metadata stored in the \System Volume Information\FsTx directory. Under the reported conditions, the exploit can expose a command shell with access to the decrypted volume after physical access to the device is obtained.
For enterprise security teams, the disclosure has increased scrutiny around recovery-path trust assumptions, particularly in TPM-only BitLocker deployments used across remote laptops, shared workstations, and field-operated devices. At the time of reporting, public sources indicated that no official Microsoft patch or CVE assignment had been released for the reported behavior.
The YellowKey BitLocker bypass centers on Windows Recovery Environment (WinRE) and how it processes Transactional NTFS (TxF) metadata during recovery. Public analysis indicates that crafted FsTx files placed on removable media, or staged through an EFI partition path, can influence WinRE behavior on affected Windows 11 and Windows Server 2022/2025 systems.
1. An attacker gains physical access to a BitLocker-protected Windows device.
2. Crafted FsTx metadata files are introduced through a USB device or EFI partition path under \System Volume Information\FsTx.
3. The target system is booted into Windows Recovery Environment (WinRE).
4. During startup, WinRE processes the Transactional NTFS (TxF) metadata from the crafted files.
5. Public analysis indicates the transaction behavior can affect X:\Windows\System32\winpeshl.ini, a file tied to WinRE launch behavior.
6. If winpeshl.ini is missing, WinRE may fall back to opening cmd.exe instead of the standard recovery interface.
7. Researchers reported that the BitLocker-protected volume becomes accessible from the command shell during the recovery sequence.
Abusing transactional NTFS (TxF)
Transactional NTFS is a Windows file-system feature that groups file operations into transactions and allows Windows to commit, roll back, or recover interrupted changes. The related transaction metadata can be stored under \System Volume Information\FsTx.
In the YellowKey BitLocker bypass, public reporting states that WinRE processes crafted TxF metadata during startup. Will Dormann’s reproduction noted that Transactional NTFS data on a USB drive appeared able to delete winpeshl.ini on another volume, specifically under X:\Windows\System32, which controls the WinRE launch behavior.
The cross-volume file modification issue
When a device boots into WinRE with crafted FsTx content, the recovery environment processes transaction data that can affect another volume. Public reporting describes this as a cross-volume file modification issue that deletes X:\Windows\System32\winpeshl.ini during the process.
That file normally helps define which recovery application WinRE launches. If it is missing, public analysis reports that WinRE can fall back to a command prompt. In reproduced tests, researchers observed cmd.exe opening while the BitLocker-protected volume was accessible, creating the practical bypass condition.
The backdoor architecture question
Chaotic Eclipse has argued that the behavior resembles a BitLocker encryption backdoor, partly because the relevant behavior appears tied to WinRE rather than standard Windows operation. However, this remains the researcher’s allegation. Public reporting has not confirmed that Microsoft intentionally designed the behavior as a forensic access mechanism or backdoor.
BitLocker without TPM: The Complete Security Analysis, Configuration, and Hardening Guide
BitLocker without TPM risks, configuration steps, and hardening guidance explained.
Reducing YellowKey BitLocker bypass exposure
The YellowKey BitLocker bypass highlights the risks associated with recovery-path abuse and TPM-only BitLocker deployments. At the time of reporting, public sources had not identified an official Microsoft patch or CVE, making endpoint hardening and recovery control important exposure-reduction measures.
Hexnode UEM: Recovery environment and BitLocker hardening
Hexnode UEM can help security teams reduce exposure by supporting Windows recovery environment management and BitLocker policy enforcement. Restricting or disabling WinRE, where operationally appropriate, can reduce access to the publicly reported exploit path associated with the YellowKey BitLocker bypass.
Security teams should also review TPM-only BitLocker deployments and consider stronger startup protections such as pre-boot PIN requirements, restricted external boot paths, and firmware-level controls.
Hexnode XDR: Visibility and investigation support
Hexnode XDR can support endpoint visibility, investigation, and response workflows on managed Windows devices. For the YellowKey BitLocker bypass, this can help teams investigate suspicious recovery activity, monitor risky device behavior, and support post-incident response actions on affected endpoints.
Featured resource
Hexnode Windows Management Solution
Simplify Windows device management, strengthen security, enforce compliance, and improve enterprise operational efficiency organization-wide.
The YellowKey BitLocker bypass has increased scrutiny around how BitLocker behaves during recovery and pre-boot operations, particularly on TPM-only deployments. The disclosure reinforces the need for layered security around full-disk encryption. Organizations should restrict recovery access and strengthen firmware protections. They should also improve endpoint visibility and enforce stronger authentication policies.
For enterprise security teams, the issue highlights the importance of reducing trust in recovery-path behavior and strengthening physical-access defenses across managed Windows devices.
Hexnode UEM and XDR can help support endpoint hardening, device visibility, and investigation workflows as part of a broader defense-in-depth strategy against recovery-environment abuse.
Strengthen endpoint recovery security
Start your Hexnode trial or explore Windows endpoint hardening controls.
A storyteller for practical people. Breaks down complicated topics into steps, trade-offs, and clear next actions—without the buzzword fog. Known to replace fluff with facts, sharpen the message, and keep things readable—politely.
