Microsoft has published information about a recent security problem classified as "BitLocker Security Feature Bypass" identified as CVE-2022-41099 which points out that Windows Recovery Environment (WinRE) images are at this time not automatically updated, but instead require manual steps to actually apply.

Installing the update normally into Windows will not address this security issue in WinRE. [..] You must apply the applicable Windows security update to your Windows Recovery Environment (WinRE).

That sounds like something only justified by exceptional circumstances, given how easily the provided instructions could results in breaking the feature altogether, and how deviating from the usual update methods will delay the updates application on many if not most systems.

A successful attacker could bypass the BitLocker Device Encryption feature on the system storage device.

"Bypass" sounds serious, but at the same time impossible given that the same disk, encrypted the same way is on disk simply either protected or not protected, never conditional on the update status of the system Microsoft has setup to maintain it. Because if it did depend on that, the described "attacker with physical access" could just downgrade the software to get rid of that pesky security update, right?

What is going on here, how can this apparent contradiction be explained and what could qualify a BitLocker-enabled Windows system to justify the extra steps to update the its (never before serviced?) WinRE system.

  • Not my original research, but apparently the WinRE image lives on an unencrypted partition on the drive. Unless there is some way that the TPM PCR can verify that this partition is valid before allowing the system to boot, in theory it seems like an attacker with physical access can simply swap out the 'patched' .wim with an vulnerable one, boot into recovery mode, and perform the bypass like that?
    – Minkus
    Commented Jan 19, 2023 at 17:27
  • the_andshrew on Reddit: 'I have a Server 2022 VM BitLocker encrypted with a VMware TPM. I mount the drive on another VM, and overwrite the ...\winre.wim file on its recovery partition with one from a Windows 11 system. I then boot the drive back up on the original VM... the OS happily boots up automatically decrypting the system drive. I can then boot into recovery which loads the Windows 11 winre.wim I swapped in.'
    – Minkus
    Commented Jan 19, 2023 at 17:30
  • reddit.com/r/sysadmin/comments/10a1enh/…
    – Minkus
    Commented Jan 19, 2023 at 17:30
  • Another helpful conversation on Reddit reddit.com/r/sysadmin/comments/10atdqe/…
    – Minkus
    Commented Jan 19, 2023 at 18:12

3 Answers 3


I am following this discussion with interest but besides the question about how to patch WinRE i have some more thoughts. I learnd from the different variants of patching that it is quite simple to replace the WinRE .wim file with a different version. It is no problem to extract this from windows ISO in an unpatched state. So why should patching solve the problem if i can use any version i want instead? I think this will lead to the result that the patching is useless. Even removing the WinRE from the device is an unclear solution - why not shrinking the partition and creating a new WinRE to start from. Not very complicated? Also - as i can not find any detail about the attack itself - could i move the HDD to a different computer? One mentioned that we might be able to protect the computer with boot password and disable external devices. O.K. this might help allthough the users will not be very happy. But this is only a solution if the attack is needing info from the computer itself like TPM data. At the end i come to the conclusion that patching is not even worth a try as it is simple to be undone by the attacker. Keep in mind - full physical access to the device. At the current state - without any information about the attack itself - i do not see any solution. If i am right with my thoughts this is dramatic problem for "confidentially" of data (MS itself declared the impact as high!). Every windows 10 and 11 device is at high risk and so is localy stored data. Does anyone have information to the attack and how it is done? Well - some may say we should not exploit this here, but do you really think that the attackers are not aware of this info right now?

  • I suspect the precise definition of "offline", "recovery or reset operation invoked" and "physical access" might be needed to explain this properly - I am just not too familiar with how Microsoft uses that language. Maybe by "recovery operation revoked" they don't mean a very protected system state after all, and the bug is somewhere in the way the live OS verifies that it is not handing the keys to an easily-compromised recovery system.
    – user287998
    Commented Jan 18, 2023 at 18:30

I only have guesses, but with that said:

  1. It might only apply to TPM-only Bitlocker. In TPM-only mode, the encryption key is available to any OS that follows the usual boot process up to a certain point. On Windows, that point is by default reaching the Windows bootloader (this is partially configurable, albeit awkwardly, by modifying the PCRs that Bitlocker checks). Since the copy of WinRE installed on the disk is also accessed through the Windows bootloader, this might mean that the relevant PCRs are the same when booting to WinRE, in which case the Bitlocker key is unsealed. Bitlocker in TPM-only mode relies on the OS user authentication to protect against online attacks, but in WinRE there might be ways to bypass the user authentication since, historically, recovery environments assume that anybody physically at the machine is authorized to service it.
  2. The bug might be a missing mitigation against an attacker extracting the key from RAM after booting but before (and without) authenticating to the OS. Normally, when the user isn't logged in (or if the session is locked), Windows disables all DMA (Direct Memory Access) that could access the relevant region of memory, where the Bitlocker key is stored (in some cases it might just block DMA from accessing certain ranges, rather than disabling it entirely). If WinRE allows some form of DMA to read the bitlocker key, then this would put the key at risk. That's especially true in TPM-only mode, but even if there's a boot-time password or external key file, an attacker who finds a booted (but locked) machine would be able to extract the key from it so long as they could do so before the machine shut down.
  3. Bitlocker includes the ability to "suspend" encryption at various times, which it does by writing to the volume metadata (in plain text) a value that can be used to decrypt the encryption key. The user can manually suspend BitLocker, but it can also happen automatically during updates that would otherwise prevent the TPM from unsealing the key (in particular, updates to the firmware or bootloader, or possibly in some cases the kernel). Possibly this "suspended" key protector was being written somewhere it shouldn't be, or derived in an unsafe way, or not erased properly when protection was un-suspended. Even through the Bitlocker protectors are written to the volume metadata (not the same as the boot volume), WinRE might sometimes be responsible for them and may have mis-handled them, leading to a vector by which a knowledgeable attacker could extract the volume encryption key as though Bitlocker was suspended even though it wasn't.

There seems to be almost no reliable information about that CVE, so it could also be something else entirely or even some combination of things.


These are not exceptional circumstances.

WinRE is an emergency / "Safe Boot"-like separate mini-install of Windows that is present on all applicable Windows systems. And because WinRE can be invoked by anyone with physical access to the device, anyone with physical access (and the knowledge) can now bypass Bitlocker.

And since WinRE is not patched by the Windows Update process, the only way to mitigate the threat is to create a separate process/script to locally apply the patch to each system currently running Bitlocker - or potentially running Bitlocker in the future - using the command-line mounting and WinRM steps provided by Microsoft.

In other words: anyone expecting Bitlocker to protect sensitive information (on a stolen laptop, etc.) needs to develop, test, and deploy a script to apply this fix.

  • I expect the level of protection to not depend on the version of software shipped on the same drive. Why would the laptop thief even care to try the version I manually updated, instead of sticking to the version that had been installed before these steps?
    – user287998
    Commented Jan 15, 2023 at 0:47
  • The vulnerability was originally patched as part of the main Windows OS. Then Microsoft realized that the same vulnerability could be exploited on the WinRE side. Once the attacker knows that, they can exploit any system that hasn't patched both sides. If we assume (as we must) that the attacker A) wants the unencrypted data and B) knows as much about the vulnerabilities as is contained in Microsoft's announcements, then not patching both sides becomes pretty difficult to justify. Commented Jan 15, 2023 at 9:02
  • 1
    Some scipts have already been written - but @Peter-Otto Weber makes some good points in his answer as to whether even patching is effective manima.de/2023/01/… github.com/halsey51013/UpdateWindowsRE-CVE-2022-41099
    – Minkus
    Commented Jan 19, 2023 at 17:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .