www.it-connect.fr
How to Protect Windows from the YellowKey Zero-Day Flaw
Microsoft has released official mitigation guidance for the zero-day security flaw nicknamed YellowKey. This vulnerability, now tracked as CVE-2026-45585, allows an attacker with physical access to a machine to bypass BitLocker encryption.
A few days ago, security researcher Nightmare-Eclipse disclosed a new set of Windows zero-day vulnerabilities. Among them was the YellowKey vulnerability, which makes it possible to bypass the BitLocker encryption mechanism. Now, anyone can exploit this vulnerability because an exploit code has been published on GitHub. That said, an attacker still needs physical access to the target machine, and as we will see later in this article, this also depends on how BitLocker is configured.
CVE-2026-45585: Microsoft Is Not Happy
This security flaw is now associated with the CVE-2026-45585 reference and a CVSS score of 6.8 out of 10. At first glance, that score may seem low because the vulnerability is easy to exploit. This is likely due to the fact that physical access to the machine is required.
In practice, this attack method consists of placing modified "FsTx" files on a USB drive or an EFI partition. Then, all you need to do is plug that media into the target computer (where BitLocker is enabled), reboot the machine to access the Windows Recovery Environment (WinRE), and hold down the CTRL key to display an elevated command prompt.
In its security bulletin, the Redmond company stated: "Microsoft is aware of a security feature bypass vulnerability in Windows, publicly referred to as YellowKey". More importantly, Microsoft did not hide its frustration with the actions of researcher Nightmare-Eclipse: "The proof of concept for this vulnerability was made public, violating coordinated vulnerability disclosure best practices." - The standoff between the two sides continues.
Microsoft and Nightmare-Eclipse at least agree on one point: the systems affected by this vulnerability. Windows 10 is not affected, unlike these versions:
- Windows 11 version 26H1 (x64)
- Windows 11 version 24H2 (x64)
- Windows 11 version 25H2 (x64)
- Windows Server 2025 (including the Core version)
Microsoft’s Recommended Mitigations
To address this threat in the absence of an immediate fix, Microsoft recommends a technical procedure to be performed manually on each machine. This may make sense on sensitive endpoints, especially for mobile users.
This procedure involves modifying the WinRE image to prevent automatic execution of the vulnerable component. Here are the six steps to follow from an elevated Command Prompt.
- Step 1: mount the WinRE image on the device
Create a folder that will serve as the mount point (for example c:\mount) and load the WinRE image into it:
mkdir C:\mount reagentc /mountre /path C:\mount- Step 2: mount the image's system registry hive
Load the image registry so that you can modify it:
reg load HKLM\WinREHive C:\mount\Windows\System32\config\SYSTEM- Step 3: modify the BootExecute value
In the hive containing the mounted registry, locate the BootExecute value under the following entry: HKLM\WinREHive\ControlSet001\Control\Session Manager.
Modify this REG_MULTI_SZ value in Session Manager by removing the autofstx.exe entry.
- Step 4: save and unload the registry hive
Once the change has been made, release the hive:
reg unload HKLM\WinREHive- Step 5: unmount the updated WinRE image
Apply the changes and close the image:
reagentc /unmountre /path C:\mount /commit- Step 6: restore BitLocker trust for your WinRE
Reset the service to permanently apply the protection to your machine's WinRE image:
reagentc /disable reagentc /enableA ready-to-use Batch script that automates all of these actions was also shared by Jernej Simončič. Here is the code he proposes:
@echo off
setlocal enabledelayedexpansion
net.exe session 1>nul 2>&1 || (
powershell -command "Start-Process -FilePath '%~dpf0' -Verb 'runas'"
exit /b
)
set MP=%SYSTEMDRIVE%\WinREMount
mkdir %MP%
echo Mounting WinRE partition, this can take a while...
reagentc /mountre /path %MP%
reg load HKLM\WinRESys %MP%\Windows\System32\config\SYSTEM
set REG=HKLM\WinRESys\ControlSet001\Control\Session Manager
for /F "usebackq tokens=2,* skip=2" %%A IN (`reg query "%REG%" /v BootExecute`) DO set OLDVAL=%%B
if "%OLDVAL%"=="" set OLDVAL=x
if "%OLDVAL%"=="%OLDVAL:autofstx.exe=X%" (
echo autofstx.exe not present in WinRE
) else (
if "%OLDVAL%"=="%OLDVAL:\0=X%" (
echo Setting empty BootExecute
reg add "%REG%" /v BootExecute /f /t REG_MULTI_SZ /d ""
) else (
set NEWVAL=%OLDVAL:autofstx.exe=%
set NEWVAL=!NEWVAL:\0\0=\0!
if "!NEWVAL:~0,2!"=="\0" set NEWVAL=!NEWVAL:~2!
echo Setting BootExecute to !NEWVAL!
reg add "%REG%" /v BootExecute /f /t REG_MULTI_SZ /d "!NEWVAL!"
)
)
reg unload HKLM\WinRESys
echo Unmounting WinRE partition, this can take a while, too...
reagentc /unmountre /path %MP% /commit
rd %MP%
echo Resetting WinRE BitLocker trust...
reagentc /disable
reagentc /enable
pauseAnother recommendation has also been issued, notably by security researcher Will Dormann: switch from TPM mode to TPM + PIN mode for BitLocker unlock. This means that a PIN must be entered at every computer startup, whereas with TPM-only mode, the security chip handles this automatically.
In reality, using a PIN with BitLocker can block the YellowKey attack. It is a viable mitigation, but one that is inconvenient for users on a daily basis. If you configure BitLocker on new machines, you can adjust your Group Policy or Intune policy to require the PIN.
Finally, note that Microsoft has not specified when the security fix will be released. The next deadline is the June 2026 Patch Tuesday, scheduled for Tuesday, June 9.
