MFA Bypass Cheat Sheet

Techniques for bypassing multi-factor authentication: response manipulation, OTP brute-force, race conditions, backup-code abuse, remember-device flaws, and broken enrollment/recovery flows. (39 payloads)

Try it interactively with the OAuth / OIDC Attack Wizard

Response & Status-Code Manipulation

(6)

Intercept the MFA-verify response and change {"success":false} to {"success":true}

If the client decides whether to grant access based on a flag in the response body, flip it in Burp/Proxy. The server never re-checks the OTP, so the session is upgraded to fully-authenticated on a forged client signal.client-side trust — the #1 broken-MFA pattern

Change HTTP 401/403 on the verify endpoint to 200 OK (and drop the error body)

Single-page apps frequently gate the post-MFA redirect on the status code alone. Rewrite the response line in the proxy; if the app proceeds to the dashboard, the verification step was never authoritative server-side.status-code-driven flows

Strip the "mfa_required":true / "otp":"pending" field from the login response

Some flows treat the absence of an MFA-required flag as 'no MFA needed'. Deleting the field on the wire can make the client skip the second factor entirely and treat the partial session as complete.fail-open on missing field

Replay the pre-MFA session/JWT against protected endpoints directly

Test whether the half-authenticated token issued before the OTP step already grants access. If /api/account works with the pre-MFA cookie/Bearer, MFA is a UI gate only and the token scope was never restricted.use jwt-decoder to inspect the partial token's claims/scopes

Force-browse past /verify-otp to /dashboard (or the post-login callback)

Skip the second-factor page by requesting the next step directly. If the destination renders with the partial session, authorization is decided per-page rather than enforced on a single server-side 'mfa_passed' state.missing server-side step enforcement

Submit the OTP endpoint with the field blank, null, [], or 000000

Loose comparisons (== in PHP, type juggling, empty-string == server-stored-empty) can validate an empty or default factor. Also try the literal 'true' or boolean true where a code is expected.type-juggling / null-comparison

OTP Brute-Force & Rate-Limit Gaps

(6)

Brute 000000–999999 against /verify with no lockout (1,000,000 keyspace)

A 6-digit numeric TOTP/SMS code is only 10^6 values; without per-account attempt limits or code expiry tied to attempts, it is fully brute-forceable. Test whether wrong codes ever lock the account or invalidate the challenge.the core OTP weakness — keyspace is tiny

Resend OTP to reset the attempt counter, then keep guessing

If requesting a new code resets the per-code failed-attempt count but the OLD code stays valid (or the new one doesn't invalidate prior attempts), you regain unlimited guesses by cycling 'Resend' between batches.counter-reset bypass of rate limiting

Rotate IPs / spoof X-Forwarded-For: 127.0.0.1 to defeat IP-based throttling

When rate limits key on source IP rather than account, cycle proxies or inject a forged forwarding header per request. If attempts/account never increment, the limit is trivially evaded.IP-keyed limits — see password-spraying for the same flaw

Check code lifetime: a TOTP valid for 30–90s with no attempt cap = brute window

Measure how long a single code stays valid and how many guesses fit in that window at the server's response rate. A long validity skew plus a fast endpoint can let you exhaust enough of the keyspace within one code's lifetime.validity-window math

Burp Intruder: numbers payload 000000-999999, Null grep on success body

Set the OTP field as the insertion point, use the Numbers payload type with min-integer-digits 6, and flag the response that lacks the failure marker. Throttle to the observed rate limit to avoid detection on authorized tests.tooling for the brute

Try the same code across the +/- 1 time-step window (clock skew)

Servers often accept the previous and next 30s TOTP step for clock tolerance, widening the valid set 2–3x. Combined with a leaked recent code, this expands what an attacker who saw one code can replay.TOTP skew tolerance

Race Conditions & Concurrency

(5)

Send 20–50 parallel /verify-otp requests with different codes in one batch

A check-then-mark-used flow (TOCTOU) on the OTP can be raced: many guesses are validated against the still-valid code before the 'used' flag is committed, multiplying effective guesses per rate-limit slot.classic OTP race — see the race-condition cheat sheet

HTTP/2 single-packet attack: duplicate the verify request to 20 tabs → 'Send group in parallel'

Burp's single-packet technique removes network jitter so all OTP attempts hit the same race window. Useful when the per-attempt counter increments lazily and a burst slips multiple guesses past the limit.precise race window via HTTP/2 multiplexing

Race the 'remember this device' toggle with the verify call

Fire the trust-device registration concurrently with verification; some backends persist the trusted-device record before the OTP result is final, planting a long-lived bypass cookie even if the code ultimately fails.race to plant a trust token

Turbo Intruder gate: queue 30 verify requests, openGate('race') to release simultaneously

Use a gate-based RequestEngine to fire all OTP attempts at once. Compare how many return success — more than one success means the code wasn't atomically consumed and the endpoint is race-vulnerable.Turbo Intruder script pattern

Race enrollment: two concurrent 'enable MFA' calls binding different secrets

Concurrent factor-enrollment requests can leave the account in an inconsistent state — e.g. one factor enabled server-side while the user sees another — letting an attacker bind a secret they control.TOCTOU during setup

Backup Codes & Recovery-Factor Abuse

(6)

Brute-force or enumerate backup/recovery codes (often short, fixed-format)

Backup codes are frequently 8–10 alphanumeric or all-digit strings with no rate limit (vendors assume low use). If the format is predictable and attempts aren't capped, the recovery path is weaker than the primary OTP.the soft underbelly of MFA

Check if backup codes are single-use and invalidated after consumption

Replay a previously-used recovery code. If it still authenticates, codes aren't burned on use — one leaked code grants repeated access. Also verify regenerating codes invalidates the old set.single-use enforcement test

Trigger 'use another method' / 'lost your device?' to downgrade to a weaker factor

Method-confusion: the fallback to SMS, email OTP, or security questions may be far weaker than the app's TOTP. Force the downgrade path and attack the easiest factor rather than the primary.factor downgrade attack

Recovery via email OTP — chain with email account takeover or OAuth flaws

If the 'forgot MFA' flow sends a reset link or code to email, the MFA is only as strong as the mailbox. A compromised or OAuth-linked email collapses the second factor entirely.recovery inherits email's weakness — see oauth-oidc

Inspect backup codes returned/cached in client storage or API responses

Some apps return the full backup-code set in a JSON response or leave it in localStorage/sessionStorage after enrollment. Pull it from DevTools or the proxy history rather than guessing.client-side disclosure

Reset-token reuse: does a password reset also clear or skip MFA?

Test whether completing a password reset issues a fully-authenticated session without re-prompting for the second factor. A reset that bypasses MFA turns email control into full account takeover.reset-flow MFA stripping

Remember-Device & Trust Abuse

(5)

Decode the 'remember device' / trusted-device cookie (base64/JWT)

Trust tokens often encode the user ID, a device fingerprint, or an expiry. If it's a readable/unsigned blob, you can forge or swap the identity to claim another user's trusted-device status.use jwt-decoder / inspect with session-compare

Replay a captured remember-device cookie from another browser/IP

If the trust token isn't bound to a fresh device fingerprint, IP, or session, exporting it (via XSS, shared machine, or proxy capture) lets an attacker skip MFA from anywhere it's replayed.token not bound to device context

Test remember-device expiry and revocation (does logout/password change kill it?)

A 30-day trust cookie that survives logout, password change, or MFA reset is a persistent bypass. Verify that security-sensitive events revoke all trusted devices server-side, not just the current cookie.broken revocation = durable bypass

Set the trust flag yourself: add remember_device=true / trust=1 to the verify request

If the client controls whether a device becomes trusted via a request parameter, set it even when the option wasn't offered. Look for the trusted-device record being created without server-side validation.client-controlled trust parameter

Forge a device fingerprint to match a target's known trusted device

When trust is keyed on a fingerprint (user-agent + screen + canvas hash) sent by the client, replicate the victim's values to impersonate their trusted device. Client-supplied fingerprints are attacker-controlled.fingerprint spoofing

Enrollment & Setup Flaws

(5)

Enroll a TOTP secret on the victim's account via IDOR on the setup endpoint

If 'enable MFA' takes a user_id or account_id you can change, bind your own authenticator to the victim's account. You then pass MFA with codes from your app, locking the victim out and owning their login.pre-emptive MFA binding via IDOR

Skip the 'confirm setup' step — is MFA enabled before the first code is verified?

Enrollment should require proving you hold the secret (entering one valid code) before activating. If the secret is bound on the QR-display step alone, an interrupted/forged setup can register a factor without confirmation.unverified enrollment

Reuse the TOTP shared secret leaked in the enrollment QR/API response

The base32 secret (otpauth://totp/...?secret=) is shown at setup. If it's logged, cached, emailed, or reachable later via API, anyone with it can generate valid codes forever — rotate-on-compromise is rarely implemented.shared-secret disclosure

Check if a fresh session can disable MFA without re-authentication / step-up

Disabling the second factor is a sensitive action that should require a password or current OTP. If a hijacked session can turn MFA off via a simple POST, the protection is removable by the very attacker it should stop.missing step-up on disable

Bind a phone number / email you control during a partially-authenticated flow

Some onboarding flows let you set the SMS/email factor destination while only half-authenticated. Point the second factor at an attacker-controlled channel so all future codes route to you.attacker-controlled delivery channel

Detection, Indicators & Hardening

(6)

Indicator: verify decision lives in the response body/status, not server state

If flipping a JSON flag or status code grants access, the second factor is advisory. Fix: persist an authoritative 'mfa_completed' boolean in the server-side session and gate every protected route on it.the root cause of most bypasses

Indicator: wrong OTPs never lock, never expire the challenge, never throttle

No per-account attempt cap + reusable code = brute-forceable. Fix: invalidate the challenge after N failures, expire codes on first failure, and rate-limit per account (not just per IP).OTP brute hardening

Indicator: parallel verify requests yield >1 success

More than one success in a burst means the code isn't atomically consumed. Fix: atomically mark-used inside the same transaction that validates (SELECT ... FOR UPDATE / compare-and-set), not check-then-mark.race hardening

Indicator: remember-device token survives logout, password change, or MFA reset

Durable trust tokens defeat remediation. Fix: bind trust to the session, sign it server-side, cap lifetime, and revoke all trusted devices on any credential or factor change.trust-token hardening

Prefer phishing-resistant factors: WebAuthn/FIDO2 over SMS/TOTP

SMS is SIM-swappable and TOTP is phishable/replayable in real time via reverse proxies (evilginx-style). WebAuthn binds the assertion to the origin, defeating credential-relay and most response-manipulation bypasses.design-level fix

Test the full matrix: login, recovery, reset, enrollment, disable, and trust paths

Bypasses cluster in the secondary flows, not the happy path. Enumerate every way to reach an authenticated session — backup codes, email recovery, password reset, device trust — and confirm each independently enforces MFA.coverage checklist

ShareX LinkedIn Reddit

Level up your security testing

Install the CLI

npx payload-playground

Explore All Tools

Encoding, hashing, JWT & more

Browse Cheat Sheets

Quick-reference payload guides

Related Cheat Sheets

Race Condition Cheat Sheet OAuth & OIDC Security Cheat Sheet Password Spraying Cheat Sheet Session & Cookie Attacks Cheat Sheet

Frequently asked questions

What is the MFA Bypass Cheat Sheet?+

It's a quick-reference collection of 39 MFA Bypass payloads for testing MFA Bypass vulnerabilities during authorized penetration testing, bug bounties, and CTFs. Every payload is copy-ready and grouped by attack context.

How do I use these MFA Bypass payloads?+

Copy any payload straight into your authorized test, or use the OAuth / OIDC Attack Wizard to apply them interactively. Only test systems you have explicit permission to assess.

Are these MFA Bypass payloads free to use?+

Yes — this cheat sheet and all MFA Bypass payloads are completely free, with no account required. Everything runs in your browser.

$loading...

Frequently asked questions

What is the MFA Bypass Cheat Sheet?+

How do I use these MFA Bypass payloads?+

Copy any payload straight into your authorized test, or use the OAuth / OIDC Attack Wizard to apply them interactively. Only test systems you have explicit permission to assess.

Are these MFA Bypass payloads free to use?+

Yes — this cheat sheet and all MFA Bypass payloads are completely free, with no account required. Everything runs in your browser.

MFA Bypass Cheat Sheet

Response & Status-Code Manipulation

OTP Brute-Force & Rate-Limit Gaps

Race Conditions & Concurrency

Backup Codes & Recovery-Factor Abuse

Remember-Device & Trust Abuse

Enrollment & Setup Flaws

Detection, Indicators & Hardening

Related Tools

Related Cheat Sheets

Frequently asked questions

MFA Bypass Cheat Sheet

Response & Status-Code Manipulation

OTP Brute-Force & Rate-Limit Gaps

Race Conditions & Concurrency

Backup Codes & Recovery-Factor Abuse

Remember-Device & Trust Abuse

Enrollment & Setup Flaws

Detection, Indicators & Hardening

Related Tools

Related Cheat Sheets

Frequently asked questions