I just spent a day or so figuring this out, and CVE-2022-41099 is... really stupid...
I decided to call this "push button decrypt".
basically when you boot to WinRE tied to an OS install, keys for the os volume are derived (this is done by having a sha256 hash of a wim in the bitlocker metadata)
anyway, WinRE does not require bitlocker recovery key when choosing to "reset my PC" and "remove everything".
When choosing "just remove my files", winre starts to decrypt the bitlocker volume at ~98%.
Hard resetting (hard power off / power on) here will reboot back into WinRE and show an error.
Clicking OK on the error will cause a reboot back to the OS, and starts windows setup which shows an "upgrade" screen.
...where Shift+F10 works to get a shell, you can then pause the decryption, remove all key protectors, then dump plaintext VMK, decrypt the FVEK with that, and use that FVEK to decrypt a disk image you made earlier.
This is the second time that Shift+F10 in setup to get a shell broke bitlocker.
The fix removes "reset my PC" -> "remove everything" from the list of options that are allowed to start with the osvolume unlocked and without entering a recovery key. (leaving only one in place: startup repair)
Because this is an issue with code running in winre usermode, this affects legacy integrity validation as well as secure boot integrity validation.