The gist of this is that an attack can use their own Time-based One-Time-Password (TOTP) code on another user’s account.

This is in part because the TOTP process takes as arguments both the assertion or the code itself and a factorId. The factorId uniquely identifies the secrets used to generate the OTP, so the server can check if the code. The problem here seems to me that the application backend shouldn’t need to rely on the client-side to provide the factorId in the first place, but even if they do it should validate ownership of that id.

As Box also didn’t validatea the ownership of the factorId an attacker could use their own OTP and Id to bypass the MFA need.

It is possible that this lack of validation was also caused due to an unexpected state. The writeup specifically uses the case where a user has SMS-based MFA enabled, and then intercepts the request to go to the TOTP endpoint instead, then proceeds to perform the above attack. A plausible scenario is that in this case where the user has no TOTP, then Box essentially fails-open and allows any factorId but had their been a registered TOTP then it would perform appropriate validation.