I check what actually happened on the backend.

The TOTP secret was generated when the app created the QR code — that part is real. But no authenticator app ever registered it. The shared secret exists on the server and nowhere else. No phone binding. No app binding. Nothing.

The frontend says MFA is on. The backend has no completed setup on record. These two things are now in different states, and the application has no mechanism to detect the gap.

The root cause is not hard to articulate. The frontend never checked. It waited for the API to tell it what happened, took that response at face value, and updated the UI accordingly. There is no server-side confirmation happening on the client side. No cryptographic verification that a real TOTP binding exists. The frontend asked the API “are we done?” and I answered for the API.

This vulnerability class goes by a few names — improper client-side validation, response manipulation, frontend trust failure — but the underlying error is always the same: UI logic that treats the API response as ground truth without validating it against actual server state. The frontend is doing the server’s job of deciding whether a security-critical operation succeeded.

The fix is not complicated. The backend should require a confirmed TOTP token exchange before returning any success state — not an error message that says “already active,” but an actual verified response. The client’s only job is to render confirmed server state, not to interpret error codes and decide setup is complete. Any response without a verified TOTP binding should drop the user back to step one, regardless of what the errorCode field claims.

One server-side check. That is the entire fix.

What stays with me about this finding is not the bypass itself.

Most MFA bypass vulnerabilities mean one thing: an attacker gets into an account they shouldn’t be in. This one does something different. This one leaves the account owner walking away believing they are protected.

Think about who this actually affects. Not the attacker — the attacker knows exactly what happened. The real target is the user. Someone who followed the setup flow, clicked Continue, saw the green checkmark, and closed the settings page with the reasonable assumption that they just hardened their account. They did everything right. The app confirmed it. There is no obvious reason to check again.

That account has zero second factor. Both the user and the application believe it has one.

The gap between what is real and what is displayed is more dangerous than a straightforward login bypass. A bypass gets detected. A security illusion just sits there, undisturbed, in an account settings screen nobody looks at twice.

The industry has a name for this kind of design failure: security theater. A feature that signals protection without providing it. The checkbox is checked. The lock icon is green. The risk is unchanged.

What makes the response manipulation angle interesting is that the theater is not intentional — it is an accident of architecture. The developers almost certainly did not design the UI to lie. They just wrote code that trusted the API response, and did not think through what happens when that trust is abused. It is a boundary problem, and it hides in codebases because it does not look like a bug. It looks like code that works.