The attack works by having an NTFS log get replayed against another partition than the one the log is stored on.
Sending the right signals to unlock Bitlocker in TPM-only mode is a necessity for recovery operations. Managing to replace the executable launched post verification is a plausible attack vector.
The weird thing is why it's possible to put the corrupting transactions on a different disk than the one being updated.
In theory I think it would be possible that it's a combination of "all recovery partitions share the same FS identifier and are verified before transaction playback" (it is a pre-packaged WIM file after all) and "the transaction log stores the FS identifier of the partition the changes are meant for", but in my opinion the latter part is a very weird architecture to choose.
If this is a backdoor, I appreciate how clever they were hiding it. If this is a bug, the person who discovered it probably has a whole lot more ready to publish.