The backdoor could be a bug, but I don't really understand how it happened.

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.