MFA Bypass by Response Manipulation: Test the Server, Not the UI
Videos that change {"success":false} to {"success":true} make MFA bypass look like a one-click trick. Most of the time they only fool the front end into showing a dashboard shell. The server still rejects every protected request.
Your job is to find out where the authentication decision lives.
Trace the whole login state machine
Use an account you own with MFA enabled. Capture the password submission, challenge creation, OTP verification, redirects, cookies, and the first authenticated API request. Label the session before and after each step.
A typical flow has at least three states:
- Password accepted, MFA pending.
- Challenge verified, session elevated.
- Fully authenticated session allowed to call protected APIs.
The bug appears when the browser controls a transition the server should own. Maybe the UI reads a Boolean and redirects. Maybe a client-supplied mfaComplete field is trusted by the next endpoint. Maybe the pre-MFA cookie already carries full privileges.
Intercept the failed OTP response and change only the value the client checks. Let the browser continue, then request a high-signal endpoint such as /api/me, security settings, or a page containing your private canary. A rendered navigation bar means nothing. A server response containing protected account data is the proof.
Better tests than flipping one Boolean
Try skipping the verification request and navigating directly to the post-login URL. Replay the pre-MFA cookie against API endpoints. Change status codes, nested role fields, redirect destinations, and challenge IDs only when the client consumes them.
Check alternate clients. Mobile and web flows sometimes hit different MFA endpoints while issuing interchangeable sessions. Recovery, remembered-device, SSO, and "trust this browser" paths are common weak links. A remembered-device token should be signed, scoped to the account, and revoked after a password reset.
Also test whether a challenge for account A can complete account B's pending login. Use two accounts you control. Swap challenge identifiers while keeping cookies separate. If challenge state is not bound to the login transaction, a valid OTP from one account may elevate another.
Separate bypass from cosmetic behavior
After your manipulation, open a fresh protected endpoint directly in a second tab or with a raw HTTP client. Perform a harmless state change, such as updating a test-only preference. Refresh the session and confirm it persists. If the server returns 401 or sends you back to MFA, document the client-side flaw if useful, but do not call it account takeover.
A real MFA bypass starts with the victim's password or a pre-auth session and ends with server-authorized access without the second factor. State those prerequisites. MFA does not compensate for a stolen full session cookie, so replaying one is not an MFA bypass.
Write the report around state
Include the untouched failed response, your modified response, cookie changes, and the protected API call that succeeds. A short state diagram helps triage see which transition is client-controlled.
Recommend enforcing MFA completion in server-side session state, issuing the full session only after verification, binding challenge IDs to user and login transaction, and applying the same gate to every API and client. The front end may decide what to display. It must never decide whether authentication happened.