How to Protect Windows from the YellowKey BitLocker Bypass (CVE-2026-45585)

YellowKey (CVE-2026-45585, CVSS 6.8) is a BitLocker security-feature bypass. An attacker with physical access places modified FsTx files on a USB drive or the EFI partition, reboots into the Windows Recovery Environment (WinRE), and holds CTRL to open an elevated command prompt — bypassing BitLocker.

Before mitigating, confirm all of the following:

1. The machine runs an affected build: - Windows 11 version 24H2 (x64) - Windows 11 version 25H2 (x64) - Windows 11 version 26H1 (x64) - Windows Server 2025 (including Server Core) 2. BitLocker is enabled on the OS drive.

Check the OS build with winver or the command below, and confirm BitLocker status.

Windows 10 is not affected — no action is required there. If BitLocker is off or the build is not listed above, the YellowKey mitigation in this guide does not apply. The CVSS score is relatively low precisely because physical access is required.

You are about to modify the WinRE image and its registry. A mistake can break recovery boot or trigger a BitLocker recovery prompt, so prepare a safety net first.

1. Record your BitLocker recovery key and store it somewhere safe and off the machine (Microsoft account, Azure AD/Entra device record, printout, or your key-escrow system).
2. Note the current WinRE state by running reagentc /info and recording the "Windows RE status" and "Windows RE location".

Keep the recovery key accessible during the whole procedure.

This tutorial modifies a live system (isReadOnly: false) and requires a backup of your recovery keys. If reagentc /info shows WinRE as Disabled, resolve that before continuing — the mount step will fail without an enabled WinRE.

Open an elevated Command Prompt (right-click Command Prompt > Run as administrator).

Create a mount folder, then load the WinRE image into it:

Mounting the WinRE partition can take a while. You must run this from an elevated prompt — a standard prompt will fail. If the mount fails, re-check reagentc /info from the previous step.

Load the WinRE image's SYSTEM hive under a temporary key (HKLM\WinREHive) so you can edit its values without affecting your live system registry:

WinREHive is just a temporary mount name — you will unload it later. Do not close the Command Prompt or reboot while the hive is loaded, or you may leave the WinRE image in an inconsistent state.

Open Registry Editor (regedit) and navigate to:

HKLM\WinREHive\ControlSet001\Control\Session Manager

Double-click the BootExecute value (type REG_MULTI_SZ) and remove the `autofstx.exe` entry (its own line). Leave any other lines intact, then click OK.

If BootExecute contains only autofstx.exe, remove that single entry so the value becomes empty.

BootExecute is a multi-string value — edit it carefully so you delete only the autofstx.exe line and preserve the others (such as the default autocheck autochk *). The reg query command is a read-only way to confirm the current contents before and after your edit.

Run the following in order from the elevated Command Prompt:

1. Unload the temporary hive.
2. Unmount and commit the modified WinRE image.
3. Disable then re-enable WinRE to reset its BitLocker trust.

The /commit flag is essential — without it your registry edit is discarded. reagentc /disable followed by reagentc /enable re-seals WinRE so BitLocker trusts it again.

Automated alternative: security researcher Jernej Simončič published a Batch script that performs all of these steps (mount, edit BootExecute, unmount with /commit, and reset WinRE trust). It self-elevates and edits the multi-string value programmatically — useful for rolling out across many endpoints.

As recommended by researcher Will Dormann, switching BitLocker from TPM-only to TPM+PIN requires a PIN at every boot, which blocks the YellowKey bypass.

• Group Policy: Configure Require additional authentication at startup under Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives, allowing/requiring a startup PIN.
• Intune: Configure the BitLocker startup authentication settings in a disk-encryption/endpoint-security policy to require a PIN with the TPM.

Apply the policy, then set the PIN on the endpoint.

This is a standalone mitigation — with TPM+PIN, an attacker cannot silently reach WinRE to run the bypass. The trade-off is daily inconvenience: users must type the PIN at each boot. For new machines, set TPM+PIN via Group Policy or Intune before encryption. This step is optional; the WinRE edit already mitigates the flaw.

Confirm the mitigation held:

1. Run reagentc /info and check that Windows RE status is still Enabled.
2. Re-mount and inspect BootExecute to confirm autofstx.exe is gone. Mount the image, load the hive, and query the value, then unload/unmount without committing (no /commit needed for a read-only check).

Microsoft has not confirmed a release date for the official fix; the next opportunity is the June 2026 Patch Tuesday (Tuesday, June 9). Keep this manual mitigation in place until a verified patch is installed, and re-check BootExecute after any WinRE-related update, since servicing can reset the recovery image.