Skip to main content
Blog

YellowKey (CVE-2026-45585): When Windows Recovery Becomes the Attack Surface

  • June 3, 2026
  • 0 replies
  • 11 views
Aaron Beardslee
Forum|alt.badge.img

Published: June 2026
Severity: CVSS 6.8 (Important) | Physical Access Required
Affected Platforms: Windows 11 24H2, 25H2, 26H1 (x64) | Windows Server 2025 | Windows Server 2025 Server Core
Patch Status: No patch available. Mitigation script released May 21, 2026.

What Is YellowKey?

YellowKey is a publicly disclosed zero-day vulnerability in Microsoft Windows that allows an attacker with brief physical access to a device to completely bypass BitLocker drive encryption and gain a SYSTEM-level command shell with full access to the protected volume. No password, recovery key, or specialized hardware is required. The attack takes approximately 60 seconds and uses a standard USB drive.

The vulnerability was disclosed on May 12, 2026, by a security researcher operating under the names Chaotic Eclipse and Nightmare-Eclipse, reportedly out of frustration with Microsoft's handling of bug reports. Microsoft subsequently assigned CVE-2026-45585 to the issue and released an interim mitigation, while a full security patch remains in development.

This is not a cryptographic weakness in BitLocker itself. The flaw lives entirely within the Windows Recovery Environment (WinRE), the built-in repair framework that runs before the main operating system loads.

How the Exploit Works

BitLocker's core promise is straightforward: even if a device is stolen or left unattended, the data on the drive stays encrypted and inaccessible without the proper credentials or TPM-bound key. YellowKey breaks that promise not by attacking the encryption, but by abusing a trusted component inside the recovery environment.

The vulnerable component is autofstx.exe, known as the FsTx Auto Recovery Utility. This binary is registered in the WinRE image's registry under Session Manager\BootExecute, which means it runs automatically when WinRE starts. Its job is to process Transactional NTFS (TxF) log files during early boot recovery. The problem is that it will process TxF logs from any attached volume, including a USB drive the attacker controls.

The attack chain breaks down like this:

  1. The attacker crafts a \System Volume Information\FsTx\ directory on a USB drive and populates it with specially constructed TxF log files.
  2. The USB is inserted into the target machine and the device is rebooted into WinRE (triggered by holding the CTRL key during the boot sequence).
  3. autofstx.exe starts via BootExecute and processes the attacker-controlled TxF logs through cross-volume transaction replay.
  4. The crafted logs instruct the replay mechanism to delete winpeshl.ini from the WinRE volume. This file controls what shell or recovery process launches inside WinRE.
  5. Without winpeshl.ini, WinRE has no configured startup process and falls back to cmd.exe running at SYSTEM privilege.
  6. Because the device uses TPM-only BitLocker, the volume master key was already released by the TPM during early boot. The drive is unlocked. The attacker now has a SYSTEM shell with full, unencrypted access to every file on the drive.

This technique works without any software installation, without existing credentials, and without network access. Any machine with a USB port that can be rebooted is a potential target under TPM-only BitLocker configurations.

Who Is Affected

The vulnerability impacts devices running:

  • Windows 11 Version 24H2, 25H2, or 26H1 (x64)
  • Windows Server 2025 (including Server Core)

The critical qualifier is the BitLocker configuration. Devices protected with TPM-only BitLocker are fully vulnerable. Devices configured with TPM+PIN are not exploitable by the current public PoC, because requiring a PIN prevents the volume master key from being released automatically during early boot. Microsoft has confirmed this distinction as part of its official advisory.

However, Chaotic Eclipse has publicly claimed to possess a working bypass for TPM+PIN configurations and stated it is being withheld. This claim has not been independently verified, and Microsoft has not confirmed it. Organizations should still treat TPM+PIN as a meaningful control, while recognizing the risk has not been fully eliminated.

The Broader Attack Chain

YellowKey does not exist in isolation. Chaotic Eclipse has released a series of Windows zero-day exploits since April 2026, and several are designed to chain together into a complete attack sequence from physical access to persistent SYSTEM-level compromise.

BlueHammer (CVE-2026-33825) is a local privilege escalation flaw that was patched and was subsequently observed being exploited in the wild.

RedSun is another privilege escalation vulnerability that Microsoft silently patched without assigning a CVE identifier. It was also observed in active exploitation shortly after public disclosure.

UnDefend is a tool that can prevent Microsoft Defender from receiving signature updates or disable it entirely.

GreenPlasma is a privilege escalation technique targeting the Windows Object Manager and CTF namespace. It allows an attacker to place an arbitrary memory section object in a SYSTEM-writable directory, redirecting trusted process paths into attacker-controlled code and achieving a SYSTEM shell without any credentials or administrator rights. There is currently no patch.

MiniPlasma revisits CVE-2020-17103, a Cloud Files filter driver vulnerability originally reported to Microsoft by Google Project Zero researcher James Forshaw in September 2020 and supposedly fixed in December 2020. Chaotic Eclipse confirmed the same issue remains present and exploitable on fully patched Windows systems as of June 2026.

The practical combined kill chain looks like this:

  • Phase 1 (physical, ~60 seconds): Insert YellowKey USB, reboot to WinRE, hold CTRL, receive SYSTEM shell, stage an implant or modified binary on the now-decrypted drive.
  • Phase 2 (next user logon): The staged payload executes at user context when the machine boots normally.
  • Phase 3 (escalation): GreenPlasma or MiniPlasma elevates the implant from a standard user context to SYSTEM.
  • Phase 4 (persistence): With SYSTEM access, the attacker installs a persistent backdoor, modifies authentication stores, or establishes a command-and-control channel.

The result is a complete, patchwork-free intrusion chain that requires no remote exploitation, no phishing, and no specialized hardware beyond a USB drive.

Mitigations

Microsoft has not released a security patch. Two interim mitigations are available.

Option 1: Remove autofstx.exe from the WinRE BootExecute registry value.

Microsoft released an automation script that safely mounts the WinRE image on each device, loads its offline SYSTEM registry hive, removes the autofstx.exe entry from Session Manager\BootExecute, unmounts and commits the updated image, and re-seals WinRE so BitLocker trust remains intact. If the entry is not present (meaning the mitigation was already applied), the script exits without making any changes.

This mitigation is targeted and effective against the current PoC, but it does not redesign the underlying Transactional NTFS replay path. The structural property that allows an external volume's TxF logs to influence WinRE behavior remains in place.

Option 2: Enable TPM+PIN BitLocker protection.

Requiring a startup PIN prevents the volume master key from being released during WinRE boot, blocking the exploit entirely under the current PoC. For already-encrypted devices, this can be configured via PowerShell:

Add-BitLockerKeyProtector C: -TpmAndPinProtector

Or via command line:

manage-bde -protectors -add C: -TPMAndPIN

For devices where the PIN option is not exposed in the UI, enable the Group Policy setting "Require additional authentication at startup" and configure the TPM startup PIN option to "Require startup PIN with TPM."

Important deployment note: The WinRE image on already-deployed machines does not update automatically. Applying the mitigation script requires deliberate manual action per device or coordinated deployment through Intune or Group Policy. Enterprise teams should not assume this will be addressed by a standard Windows Update pass. This is the same deployment challenge that plagued the mitigation for CVE-2022-41099. Adoption was poor then, and the dynamics are identical here.

Detection Opportunities

YellowKey creates a challenging detection environment because the exploit itself occurs in the pre-OS WinRE phase, where most endpoint telemetry does not operate. There is no network traffic, no credential stuffing, no browser exploit, and no dropped binary on the live OS. If an attacker uses removable media and removes it after the exploit, the host may retain very little evidence.

That said, three meaningful detection windows exist.

Before the attack (USB staging artifact): The attacker must place a \System Volume Information\FsTx\ directory on the USB drive before deployment. If this drive is connected to a monitored Windows endpoint at any point, Sysmon Event ID 11 (FileCreate) configured to cover non-system drive letters can surface this unusual directory structure. The presence of a FsTx directory under System Volume Information on a removable volume is highly abnormal in legitimate operations.

Mitigation gap (exposure confirmation): Windows Security Event ID 4657 or Sysmon Event ID 13 can surface reads or modifications to the WinRE BootExecute registry key. If autofstx.exe is still present in that value, the device is unmitigated and vulnerable. This is a viable threat hunting query for assessing fleet exposure.

After the attack (WinRE image tampering or staged implant execution): Unauthorized writes to winre.wim or the WinRE SYSTEM hive from processes other than known-legitimate tools like reagentc.exe or dism.exe are a strong indicator of an attacker reversing the mitigation or modifying the recovery image. Post-exploitation, the GreenPlasma and MiniPlasma LPE chains produce detectable process execution anomalies, including unexpected SYSTEM-integrity shells spawned by low-privilege parents and CTFMON spawning command interpreters.

A note on Sysmon configuration and removable drive coverage: Most default Sysmon configurations, including the upstream SwiftOnSecurity base, do not include FileCreate (Event ID 11) rules for non-system drive letters. Teams relying on Sysmon for FileCreate coverage of USB staging artifacts will need to explicitly add include rules for the drive letter ranges used by removable media in their environment. The Securonix Threat Research maintained fork of the FT-Sysmon Config (github.com/fluffybunnies-h4x/FT-Sysmon-Config) does address this gap for a related but distinct vector: its ImageLoad (Event ID 7) section explicitly includes rules for drive letters D through Z under the comment "Imageload from mounted drive." This means that if an attacker stages a malicious DLL or executable on a USB drive and a process on the endpoint loads it, that ImageLoad event will fire. This is directly relevant to the YellowKey post-exploitation phase, where an attacker could drop a payload DLL onto the now-decrypted drive during WinRE access and have it loaded on next boot. For the earlier USB staging artifact detection (the FsTx directory creation), teams should add explicit FileCreate path rules for non-system drive letters on top of the existing config.

Summary for Security Teams

CVE-2026-45585 (YellowKey) is a practical, low-barrier threat to any organization relying on TPM-only BitLocker to protect unattended devices, stolen laptops, or systems in physically accessible locations. It does not require advanced attacker capabilities. The public PoC is functional and available, and prior disclosures from the same researcher were quickly adopted by threat actors after release.

The mitigation is available but requires active deployment. TPM+PIN is the most effective defensive posture until a security update ships. Fleet-wide exposure assessment should be a priority, particularly for mobile workforces, executive devices, travel laptops, and any system that could realistically be in an attacker's hands for 60 seconds.

The broader Chaotic Eclipse disclosure campaign also warrants monitoring. GreenPlasma and MiniPlasma remain unpatched and represent viable privilege escalation paths for any attacker who achieves initial code execution through YellowKey or any other vector.

References

H4X

Terms & ConditionsAccessibility statement