EDIT: Mar 22, 2023
IMPORTANT: Microsoft now has a script available to patch the Win RE environment on running systems. I strongly suggest running their script to address this issue. Please see the Mar 22, 2023 edit at the top of post #24 in this thread for details.
If you read Shawn's post today regarding the Jan 10, 2023 Patch Tuesday Security Update, you may have noticed this note as the first thing in the post:

Reference:
www.elevenforum.com
The gist of this that if you encrypt your OS drive with BitLocker and someone gains physical access to your computer, they could potentially exploit this vulnerability to gain access to your encrypted data. If you use BitLocker on your OS drive and you have a Recovery Partition, this affects you!
This is a pretty big deal. Unfortunately, the documentation MS has regarding this is abysmal. Let me explain.
Let's start with the actual vulnerability...
msrc.microsoft.com
The solution to this issue involves a manual procedure to update the WinRE.wim located on your recovery partition. The procedure for doing this can be found here:
Note that you want to follow the procedure in the section called "Apply the update to a running PC".
Now, here is where things get messy:
First, I have a Recovery Partition with a size of 633 MB. That seems to be the size that Windows is creating the partition these days. I just reinstalled a few days ago, so this is a fresh installation. Unfortunately, the procedure to update the recovery environment fails due to a lack of space. It doesn't tell you that, instead it spits out this gem of a message:
REAGENTC.EXE: Operation failed: 70
REAGENTC.EXE: An error has occurred.
Well, it turns out that I always update my Windows images and had already done so today for patch Tuesday. One of the components that I update in the WinRE.wim. So, to my thinking, I could simply take the updated WinRE.wim from my Windows image and replace the one on my recovery partition. Bzzzz, wrong answer. Next contestant!
I'll spare you a lot of techno detail here, but the mechanism for updating the WinRE.wim, according to Micosoft's own docs, is to apply the "Safe OS Dynamic Update" to the WinRE.wim image (Safe OS is another term for the Windows Recovery Environment). However, through trial and error I discovered that the update for the Recovery Environment was actually contained within the Latest Cumulative Update (LCU). Again, Microsoft's own docs show that the LCU is not applicable to the Recovery Environment, but clearly this is a load of horse manure.
Yet more: I think that I now have a procedure worked out for applying the fix to running systems. After further testing I'll post a step by step procedure here. Please note that Microsoft states that only WinRE in a running environment is affected by this issue; WinRE on your Windows images are not affected. However, since their procedures are not properly updating the Windows ISO image, any machine to which you install Windows will require that you manually fix the Recovery Environment UNLESS you break with the Microsoft documented procedures and you apply the LCU to the WinRE.wim.
I'll post more when I have this throughly worked out and debugged.
In the meantime, if anyone here might be affected by this issue, I would appreciate you letting me know if you have interest in detailed mitigation procedures. If there is interest, I'll make the extra effort to create a batch file that should automate the procedure. If there is no interest, I'll save myself the effort
.
IMPORTANT: Microsoft now has a script available to patch the Win RE environment on running systems. I strongly suggest running their script to address this issue. Please see the Mar 22, 2023 edit at the top of post #24 in this thread for details.
If you read Shawn's post today regarding the Jan 10, 2023 Patch Tuesday Security Update, you may have noticed this note as the first thing in the post:

Reference:

KB5022303 Cumulative Update for Windows 11 Build 22621.1105 (22H2)
UPDATE 1/26: https://www.elevenforum.com/t/kb5022360-cumulative-update-for-windows-11-build-22621-1194-22h2.12214/ January 10, 2023 - KB5022303 (OS Build 22621.1105) Important: For Windows Recovery Environment (WinRE) devices, see the Special instructions for Windows Recovery Environment...

The gist of this that if you encrypt your OS drive with BitLocker and someone gains physical access to your computer, they could potentially exploit this vulnerability to gain access to your encrypted data. If you use BitLocker on your OS drive and you have a Recovery Partition, this affects you!
This is a pretty big deal. Unfortunately, the documentation MS has regarding this is abysmal. Let me explain.
Let's start with the actual vulnerability...
Security Update Guide - Microsoft Security Response Center
The solution to this issue involves a manual procedure to update the WinRE.wim located on your recovery partition. The procedure for doing this can be found here:

Note that you want to follow the procedure in the section called "Apply the update to a running PC".
Now, here is where things get messy:
First, I have a Recovery Partition with a size of 633 MB. That seems to be the size that Windows is creating the partition these days. I just reinstalled a few days ago, so this is a fresh installation. Unfortunately, the procedure to update the recovery environment fails due to a lack of space. It doesn't tell you that, instead it spits out this gem of a message:
REAGENTC.EXE: Operation failed: 70
REAGENTC.EXE: An error has occurred.
Well, it turns out that I always update my Windows images and had already done so today for patch Tuesday. One of the components that I update in the WinRE.wim. So, to my thinking, I could simply take the updated WinRE.wim from my Windows image and replace the one on my recovery partition. Bzzzz, wrong answer. Next contestant!
I'll spare you a lot of techno detail here, but the mechanism for updating the WinRE.wim, according to Micosoft's own docs, is to apply the "Safe OS Dynamic Update" to the WinRE.wim image (Safe OS is another term for the Windows Recovery Environment). However, through trial and error I discovered that the update for the Recovery Environment was actually contained within the Latest Cumulative Update (LCU). Again, Microsoft's own docs show that the LCU is not applicable to the Recovery Environment, but clearly this is a load of horse manure.
Yet more: I think that I now have a procedure worked out for applying the fix to running systems. After further testing I'll post a step by step procedure here. Please note that Microsoft states that only WinRE in a running environment is affected by this issue; WinRE on your Windows images are not affected. However, since their procedures are not properly updating the Windows ISO image, any machine to which you install Windows will require that you manually fix the Recovery Environment UNLESS you break with the Microsoft documented procedures and you apply the LCU to the WinRE.wim.
I'll post more when I have this throughly worked out and debugged.
In the meantime, if anyone here might be affected by this issue, I would appreciate you letting me know if you have interest in detailed mitigation procedures. If there is interest, I'll make the extra effort to create a batch file that should automate the procedure. If there is no interest, I'll save myself the effort

Last edited:
My Computers
System One System Two
-
- OS
- Win11 Pro 24H2
- Computer type
- PC/Desktop
- Manufacturer/Model
- Self-built
- CPU
- Intel i7 11700K
- Motherboard
- ASUS Prime Z590-A MB
- Memory
- 64GB (Waiting for warranty replacement of another 64GB for 128GB total)
- Graphics Card(s)
- No GPU - Built-in Intel Graphics
- Sound Card
- Integrated
- Monitor(s) Displays
- HP Envy 32
- Screen Resolution
- 2560 x 1440
- Hard Drives
- 1 x 1TB NVMe SSD
1 x 2TB NVMe SSD
1 x 4TB NVMe SSD
3 x 512GB 2.5" SSD
1 x 4TB 2.5" SSD
5 x 8TB Seagate Barracuda HDD
- PSU
- Corsair HX850i
- Case
- Corsair iCUE RGB 5000X mid tower case
- Cooling
- Noctua NF-S12A chromax.black.swap case fans (Qty. 7) & Home Computer Specifications, Configuration, and Usage Notes General Specifications ASUS Prime Z590-A motherboard, serial number M1M0KC222467ARP Intel Core i7-11700K CPU (11th Gen Rocket Lake / LGA 1200 Socket) 128GB Crucial Ballistix RGB DDR4 3200 MHz DRAM (4 x 32GB) Corsair iCUE RGB 5000X mid tower case Noctua NH-D15 chromax.black CPU cooler Noctua NF-S12A chromax.black.swap case fans (Qty. 7) & Corsair LL-120 RGB Fans (Qty. 3)
- Keyboard
- Corsair K70 Max RGB Magnetic Keyboard
- Mouse
- Logitech MX Master 3
- Internet Speed
- 1Gb Up / 1 Gb Down
- Browser
- Edge
- Antivirus
- Windows Defender
- Other Info
- The five 8TB drives and three 512GB SSDs are part of a DrivePool using StableBit DrivePool software. The three SSDs are devoted purely to caching for the 8TB drives. All of the important data is stored in triplicate so that I can withstand simultaneous failure of 2 disks.
Networking: 2.5Gbps Ethernet and WiFi 6e
-
- Operating System
- Win11 Pro 23H2
- Computer type
- Laptop
- Manufacturer/Model
- Lenovo ThinkBook 13x Gen 2
- CPU
- Intel i7-1255U
- Memory
- 16 GB
- Graphics card(s)
- Intel Iris Xe Graphics
- Sound Card
- Realtek® ALC3306-CG codec
- Monitor(s) Displays
- 13.3-inch IPS Display
- Screen Resolution
- WQXGA (2560 x 1600)
- Hard Drives
- 2 TB 4 x 4 NVMe SSD
- PSU
- USB-C / Thunderbolt 4 Power / Charging
- Mouse
- Buttonless Glass Precision Touchpad
- Keyboard
- Backlit, spill resistant keyboard
- Internet Speed
- 1Gb Up / 1Gb Down
- Browser
- Edge
- Antivirus
- Windows Defender
- Other Info
- WiFi 6e / Bluetooth 5.1 / Facial Recognition / Fingerprint Sensor / ToF (Time of Flight) Human Presence Sensor