SEKurity GmbH Logo
General

BitLocker Bypassed – Why a Fully Patched Windows 11 Isn't Enough

BitUnlocker and YellowKey show that BitLocker bypasses don't break cryptography — they exploit the trust chain around WinRE, TPM, and Secure Boot.

Alexander Sturz

Founder & Red Team Lead

12 min read
Share:

Executive Summary

In mid-2025, Microsoft’s STORM team presented BitUnlocker — four vulnerabilities that showed how BitLocker can be bypassed via the Windows Recovery Environment (WinRE). The patches shipped in July 2025; the public disclosure followed at Black Hat USA and DEF CON 33 in August 2025. In May 2026, YellowKey (CVE-2026-45585) added another vulnerability on the same attack surface.

What is remarkable here is not the existence of individual vulnerabilities. What is remarkable is that both disclosures build on the same design decision: for Windows to be repairable, BitLocker must trust the recovery environment.

Anyone who wants to understand why a fully patched Windows system can still be vulnerable has to understand how TPM, PCRs, Secure Boot, WinRE and the recovery partition interact.

BitLocker Does Not Protect the Disk

Many administrators describe BitLocker, in simplified terms, as disk encryption.

Technically that is not wrong, but it is incomplete.

The real security question is not:

Is the data encrypted?

But rather:

Under what conditions is the key released?

Breaking the XTS-AES used by BitLocker (128-bit by default, optionally 256-bit) is practically impossible, provided no trivial key is used. This is why modern attacks do not target the cryptography, but the mechanism that decides when the key may be used.

This is exactly where the TPM comes in.

TPM, PCRs and the Actual Chain of Trust

A common simplification is:

The TPM secures the key.

Technically, something different happens.

During startup, firmware and boot components each measure the next component in the boot chain. The resulting hash values are written into the TPM’s Platform Configuration Registers (PCRs) via so-called PCR-Extend operations.

Simplified:

UEFI Firmware
      |
      |-- measures next component
      |
      |-- computes hash
      |
      +-- PCR Extend
               |
               v
          TPM PCR Register

The TPM does not assess whether something is “secure” or “insecure”.

It merely stores the measurements in a tamper-resistant manner.

The decisive factor is which of these registers BitLocker actually includes in its sealing. The default profile of modern Windows installations with Secure Boot covers PCR 7 and PCR 11:

PCR7  -> Secure Boot state
         (policies, certificates)

PCR11 -> BitLocker access control
         (seal/unseal state machine)

PCR 11 is the actual “lock” against which BitLocker seals the key.

In addition, there is an extended profile that also measures early boot components:

PCR0  -> CRTM and firmware measurements

PCR2  -> Option ROMs

PCR4  -> Boot Manager / Boot Loader

These three registers are not part of the BitLocker policy by default. This becomes relevant for the attacks later: anyone who re-adds PCR 0/2/4 makes the TPM notice a change to the firmware and boot-manager chain — and that is precisely what blocks the downgrade variant described further below. Which PCRs are actually used depends on hardware, firmware and configuration.

Sealing and Unsealing: What BitLocker Actually Does

When BitLocker is enabled, the Volume Master Key is not simply stored on the disk.

Instead, it is sealed against a defined PCR state.

Simplified:

Volume Master Key
        |
        v
TPM Seal Operation
        |
        v
Released only on matching PCR values

At system start, Windows then tries to unseal the key again.

If the PCR values are identical to the state at sealing time, the key is released.

Otherwise, the BitLocker recovery prompt appears.

PCR values match
        |
        v
Unseal successful
        |
        v
Windows boots

PCR values differ
        |
        v
Recovery key required

Important:

The TPM does not check whether Windows has been compromised.

It only checks whether the measured boot chain matches the expected state.

Why BitLocker Must Trust WinRE

This is where the actual problem begins.

With WinRE, Windows has a recovery environment for repairs, resets and diagnostics.

When Windows no longer boots, WinRE should still be able to access the encrypted operating system.

Without this capability, many repair operations would be impossible.

Microsoft therefore had to make a design decision:

Normal boot
    |
    v
Windows

Recovery boot
    |
    v
WinRE

Both paths must be able to gain access to the encrypted operating system.

It is precisely from this that the later attack surface arises.

The Recovery Partition: The Actual Attack Point

A typical Windows system looks, simplified, roughly like this:

+--------------------------------+
| EFI System Partition           |
+--------------------------------+

+--------------------------------+
| Recovery Partition             |
|                                |
| WinRE.wim                      |
| ReAgent.xml                    |
| Boot.sdi                       |
| BCD                            |
| ResetConfig.xml                |
+--------------------------------+

+--------------------------------+
| BitLocker Volume (C:)          |
|                                |
| Windows                        |
| Users                          |
| Applications                   |
+--------------------------------+

Many administrators overlook an important point here:

The recovery partition is normally not BitLocker-protected.

This is not a misconfiguration.

It could technically be encrypted — after all, the boot manager also unlocks the operating-system volume.

But it deliberately is not: if the recovery environment were bound to the same encryption, it would be unavailable precisely when the OS volume can no longer be unlocked — that is, in the repair scenario.

WinRE is therefore kept on its own partition, which is not covered by the BitLocker policy of the operating-system drive — independent of the unlock state of C:.

Why Secure Boot Does Not Solve the Problem

The next common assumption is:

But that’s what Secure Boot is for.

Secure Boot, however, solves a different problem.

Secure Boot verifies whether loaded components originate from a trusted signature chain.

The flow looks, simplified, like this:

UEFI
 |
 v
Secure Boot
 |
 v
Boot Manager
 |
 v
WinRE
 |
 v
BitLocker Unseal
 |
 v
Vulnerability

The attacks do not occur before Secure Boot.

They occur after successful Secure Boot validation, inside an already trusted environment.

Secure Boot therefore works correctly.

It merely protects against a different class of attack.

There is, however, a more subtle interaction: Secure Boot trusts not only the current Microsoft components, but also older ones that are still validly signed. It is precisely this property that makes the downgrade attack described below possible — there, Secure Boot is not bypassed; rather, its trust in old, not-yet-revoked signatures is exploited.

BitUnlocker: Four Vulnerabilities, One Common Idea

The BitUnlocker vulnerabilities disclosed in 2025 differ significantly in technical detail.

The underlying attack chain, however, is nearly identical:

Offline access
        |
        v
Tampering with recovery components
        |
        v
WinRE starts
        |
        v
SYSTEM privileges in WinRE
        |
        v
BitLocker already unlocked
        |
        v
Access to C:

The individual CVEs use different components:

  • Boot.sdi
  • ReAgent.xml
  • SetupPlatform.exe
  • ResetSession.xml
  • BCD recovery sequences

The technical manifestation differs.

The objective stays the same:

Gain control over an environment that BitLocker already trusts.

For the Deep Divers

How one of these vulnerabilities works at the byte level is best followed through CVE-2025-48800 (tracked as CVE-2025-48804 in the public PoC): the boot.sdi container file has a blob table whose WIM entry points to the location of the image to be booted. The unpatched boot manager verifies the hash at the original position but boots from the one specified in the entry — the two are not bound together. An attacker appends their own WIM to the file and bends the offset: the original is verified, the manipulated image is started. Combined with an older, PCA-2011-signed boot manager, this yields a SYSTEM shell in an unsealed WinRE.

The full mechanics (the patch_sdi.py script, the blob-table indirection and the PCA-2011 downgrade chain) are documented by the public PoC: garatc/BitUnlocker.

Why the Patches Do Not Solve the Root Problem

Microsoft has patched the individual vulnerabilities.

That does not mean, however, that the underlying attack surface has disappeared.

WinRE Is Updated Separately

The file WinRE.wim is not maintained through the normal cumulative Windows updates.

Instead, so-called Safe OS Dynamic Updates are used.

A system can therefore appear fully up to date while the recovery environment is considerably older.

KB5034441 Made the Problem Visible

In early 2024, KB5034441 failed on numerous Windows installations.

The cause was frequently a recovery partition that was too small.

The actual problem, however, was organizational in nature:

Many administrators never noticed that the update had failed.

Not Every Attack Surface Lives in the WIM

Several attack paths target files outside the actual WinRE.wim.

These include, for example:

  • ReAgent.xml
  • BCD
  • Boot.sdi
  • ResetSession.xml

The decisive factor here is the TPM’s measurement scope: the WIM file is measured — not the surrounding, unsigned configuration files on the recovery partition.

TPM measurement
    |
    |-- WinRE.wim        -> measured, signed
    |
    +-- ReAgent.xml      -> NOT measured
       BCD                 NOT measured
       Boot.sdi            NOT measured
       ResetSession.xml    NOT measured

This is exactly why attacks such as CVE-2025-48003 (ReAgent.xml) or CVE-2025-48818 (BCD) survive even when WinRE.wim itself is patched: they modify a file that never enters a PCR. These components are relevant to the chain of trust but lie outside the measured recovery image.

The Signed Downgrade: Why Even a Patched WinRE Is Not Enough

Up to this point, one could object: then I’ll just update WinRE consistently, and the problem is solved.

This assumption falls short — for one fundamental reason.

An attacker with offline access does not depend on attacking the WinRE.wim present on the system. They can bring along an older version of the boot manager and recovery environment that is still validly signed by Microsoft and that still contains the already-patched vulnerabilities.

Attacker brings along:
older, signed bootmgfw.efi / WinRE.wim
        |
        v
Secure Boot verifies signature
        |
        v
Signature valid (PCA 2011 in db, not in dbx)
        |
        v
Old vulnerability chain runs
        |
        v
SYSTEM context in WinRE

The core: Secure Boot checks whether a signature is valid — not whether it is current. As long as the corresponding Microsoft certificate (historically “Windows Production PCA 2011”) is present in the allowed database db and has not been revoked via the revocation list dbx, the firmware will accept even a two-year-old, vulnerable component — for example, from a USB stick.

Why Microsoft Doesn’t Simply Patch It Away

The obvious thought is: then Microsoft should just revoke the old signatures via dbx.

In practice, this happens only very hesitantly. A faulty or overly broad dbx revocation can render systems unbootable — a revoked boot binary still sitting somewhere on a recovery or installation environment leads to total failure. The BlackLotus precedent showed that such revocations take over a year to roll out broadly, and even then often only take effect via manual opt-in.

As long as the old signatures are not present in dbx everywhere, the downgrade path remains open — regardless of how current the WinRE installed on the system is.

The extended PCR profile (PCR 0/2/4) would be an effective lever here: it would notice the swap of the boot manager and refuse the unsealing. By default, however, it is not active.

YellowKey: Why the Story Began Anew in 2026

In May 2026, the YellowKey vulnerability was disclosed.

The technical implementation differs from BitUnlocker, but the chain of trust remains the same.

Simplified:

BootExecute
      |
      v
autofstx.exe
      |
      v
Replay of NTFS transactions
      |
      v
Tampering with WinRE files
      |
      v
Fallback to cmd.exe
      |
      v
SYSTEM context

YellowKey shows once again:

BitLocker’s cryptography is not broken.

Instead, an environment is attacked that already has access to the decrypted operating system.

TPM-only versus TPM+PIN

For practice, this distinction is decisive.

TPM-only

TPM
 |
 v
Automatic release
 |
 v
Windows boots

An attacker with physical access can attempt to exploit the chain of trust around WinRE.

TPM + PIN

TPM
 |
 v
PIN required
 |
 v
Unseal
 |
 v
Windows boots

Without knowledge of the PIN, the attacker cannot use the automatic unsealing path.

For lost or stolen devices, TPM+PIN therefore remains one of the most effective protective measures.

Which Questions Organizations Should Be Able to Answer

The most important question is not:

Is BitLocker enabled?

But rather:

  • Which WinRE version is running on my endpoints?
  • Are Safe OS Dynamic Updates being installed successfully?
  • Where is TPM-only being used?
  • Where is TPM+PIN being used?
  • Is WinRE even needed?
  • Are recovery boots being monitored?
  • Can older recovery components be detected?

Anyone who cannot answer these questions may not know the actual security state of their endpoints.

First Concrete Checks

A starting point can be made with built-in tools. Status and path of the recovery environment:

reagentc /info

Then check the actual version of the WinRE image file — it reveals whether the Safe OS Dynamic Updates have arrived at all:

Get-WindowsImage -ImagePath "R:\Recovery\WindowsRE\winre.wim" -Index 1 | Select-Object Version, SPBuild

And finally, whether the system is running in TPM-only mode at all or already requires a PIN:

manage-bde -protectors -get C:

If the WinRE version and the installed patch level diverge significantly, or if the protector shows only “TPM”, there is a need for action.

Conclusion

BitUnlocker and YellowKey do not reveal a weakness in BitLocker’s cryptography.

Rather, they show that modern attack chains exploit the trust assumptions around BitLocker.

Anyone who wants to understand BitLocker has to consider the entire chain:

UEFI
 |
 v
Secure Boot
 |
 v
Boot Manager
 |
 v
TPM PCRs
 |
 v
WinRE
 |
 v
Windows

The actual lesson is therefore:

BitLocker does not protect data through encryption alone.

BitLocker protects data through trust.

And it is precisely this trust that is today the primary target of attack.

Sources

Tags

#BitLocker #Windows #WinRE #BitUnlocker #YellowKey #CVE-2026-45585

About the Author

Alexander Sturz

Founder & Red Team Lead

Active Directory Ninja and offensive security expert specializing in enterprise infrastructure compromise and post-exploitation techniques.

Related Articles