YellowKey CVE-2026-45585 mitigation: WinRE autofstx fix, TPM+PIN, no patch yet

TL;DR

---

YellowKey now has a CVE — CVE-2026-45585 — and Microsoft has released pre-patch mitigation guidance.
When I wrote the previous YellowKey and GreenPlasma article, YellowKey was unpatched, had no CVE, and had no official mitigation.
What changed this round is that Microsoft has spelled out, in the MSRC advisory, the work to do between now and the eventual patch.

MSRC rates it Important, CVSS 6.8.
The attack vector is Physical, so physical access is required.
On the other hand, confidentiality, integrity, and availability are all rated High: a successful exploit reaches the data on the BitLocker Device Encryption-protected system drive.

According to The Hacker News, the affected products are Windows 11 24H2 / 25H2 / 26H1 (x64), Windows Server 2025, and Windows Server 2025 Server Core.
Around the original PoC, Windows Server 2022 was sometimes mentioned as affected, but the MSRC list above is the canonical scope to align with now.

The attack vector also widened.
The earlier writeup focused on USB drives, but with the MSRC advisory and follow-up coverage, the EFI system partition is now explicitly named as another place to drop the crafted FsTx files.
That is a less restrictive precondition than “plug in a USB stick”: if an attacker can briefly write to the EFI partition (for instance via temporary admin access), the actual exploit fires later with physical access alone.

Stop autofstx.exe from auto-starting inside WinRE

The core of Microsoft’s mitigation is to mount the WinRE (Windows Recovery Environment) image and remove autofstx.exe from the BootExecute registry value.
autofstx.exe is the FsTx Auto Recovery Utility, which handles Transactional NTFS recovery.

YellowKey abused the fact that, at WinRE boot, FsTx-related data on an attached external volume gets processed and the recovery environment’s startup behavior gets bent.
Will Dormann explained that removing autofstx.exe from BootExecute stops the Transactional NTFS replay that ends up deleting winpeshl.ini.

The Microsoft procedure roughly looks like this:

Step	Target
reagentc /mountre	Mount the WinRE image on the device
reg load	Load the SYSTEM hive from the mounted WinRE
Edit BootExecute	Remove autofstx.exe from HKLM\WinREHive\ControlSet001\Control\Session Manager
reagentc /unmountre /commit	Persist changes back to the WinRE image
reagentc /disable and reagentc /enable	Rebuild the BitLocker / WinRE trust relationship

Unlike a normal Windows Update, this work touches each device’s own WinRE image directly.
Even when distributed via Intune or other configuration management, the operation is not “patch the OS and you’re done” — it includes verifying WinRE image state per device.

The deeper structural point is what Will Dormann raised next.
In his Infosec Exchange post, he argues that the underlying issue is that “a \System Volume Information\FsTx directory on one volume has the ability to modify the contents of another volume when it is replayed.”
Stripping autofstx.exe from BootExecute stops the specific exploit chain that deletes winpeshl.ini, but the FsTx design property — an external volume’s transaction log influencing the WinRE internal volume — stays in place.
This MSRC mitigation closes one trigger; it is not a redesign of the Transactional NTFS replay path.

Add a PIN to TPM-only BitLocker

The second mitigation is to add a startup PIN to TPM-only BitLocker configurations.
On devices already encrypted with a TPM-only protector, Microsoft’s guidance is to use PowerShell (Add-BitLockerKeyProtector C: -TpmAndPinProtector) or cmd (manage-bde -protectors -add C: -TPMAndPIN).

On devices where the PIN option is not exposed, enable the group policy Require additional authentication at startup, then set Configure TPM startup PIN to Require startup PIN with TPM.
On unencrypted devices, configure that policy via Intune or Group Policy first, and then enable BitLocker.

The decision here is not “do we add a PIN?” — it is whether the device’s threat model includes theft, temporary handover, repair drop-off, or any scenario where the device leaves the owner’s hands.
TPM-only is operationally light because the device boots without user input.
The flip side: under physical-access BitLocker bypasses, TPM-only is the first configuration to check.

That said, Chaotic Eclipse has attached a caveat to how far TPM+PIN actually carries you.
The Hacker News and Help Net Security report that the researcher says they are holding back a separate PoC that bypasses TPM+PIN configurations.
YellowKey (CVE-2026-45585) is, strictly, a break against TPM-only-equivalent setups, and TPM+PIN is the direct mitigation MSRC recommends — but if the researcher’s claim holds, switching to TPM+PIN does not amount to “now this device is permanently safe.”
For devices with a heavier threat model (theft, seizure), pair the TPM+PIN switch with a review of recovery key escrow targets, who can reach WinRE, and device loss detection.

This is not the patch

MSRC states that the CVE was issued “to provide mitigations until a security update is available.”
In other words, as of May 21, 2026, this is not a permanent fix.
Microsoft’s Exploitability assessment is Exploitation More Likely, reflecting the public PoC.

That said, MSRC’s exploitation status is Exploited: No.
What has been confirmed so far is the public PoC plus independent researcher reproduction; Microsoft has not confirmed in-the-wild attacks.

In the advisory, Microsoft also notes that it is aware of “a security feature bypass vulnerability in Windows publicly referred to as YellowKey,” and that “the proof of concept for this vulnerability has been made public, violating coordinated vulnerability best practices.”
The friction with the research side, which started with the RedSun silent fix, did not fully subside with the CVE assignment and the official mitigation.
The timing of a permanent patch is unannounced as of this writing; whether the June Patch Tuesday cycle (or later) will ship the fix is not yet committed.

Operationally, that gap matters.
Lost devices, traveled devices, and high-sensitivity devices should get one of the two mitigations — WinRE rework or TPM+PIN — soon.
For stationary devices under strong physical-access control, there is room to validate side effects before staged rollout.

What changed since the previous article

The previous article treated YellowKey as “an unpatched public PoC with no official mitigation.”
At that point, disabling WinRE, moving to TPM+PIN, and tightening physical security were the available self-defense options.

After the MSRC release, the decision axis is much more concrete:

Previous	Now
No CVE	CVE-2026-45585
No official mitigation	Step-by-step WinRE autofstx.exe removal
TPM+PIN was a stopgap idea	Microsoft explicitly recommends moving TPM-only to TPM+PIN
Scope from news + PoC	Windows 11 24H2 / 25H2 / 26H1, Server 2025 family

YellowKey is not an attack that breaks BitLocker’s cryptography — it reaches the protected volume via the WinRE boot path.
That is why the mitigation also is not “change the encryption algorithm” but “do not let FsTx auto-recovery run inside WinRE” and “require a PIN at startup.”

For YellowKey, the work item shifted from “reproduce the PoC” to “inventory WinRE images and BitLocker protector configuration.”

References

• MSRC: CVE-2026-45585 Windows BitLocker Security Feature Bypass Vulnerability
• MSRC API: CVE-2026-45585
• The Hacker News: Microsoft Releases Mitigation for YellowKey BitLocker Bypass CVE-2026-45585 Exploit
• Help Net Security: Microsoft provides mitigation for “YellowKey” BitLocker bypass flaw (CVE-2026-45585)
• Bleeping Computer: Microsoft shares mitigation for YellowKey Windows zero-day
• SecurityWeek: Microsoft Rolls Out Mitigations for ‘YellowKey’ BitLocker Bypass
• Will Dormann on Infosec Exchange: CVE-2026-45585 commentary
• Microsoft Learn: Configure BitLocker