My name is Hassan Jawaid, and I have pursued a dynamic career in security research, uncovering critical vulnerabilities and contributing to the safety of digital ecosystems. In this writeup, I want to shed light on a critical security aspect — multi-factor authentication (MFA). While MFA is designed to bolster security, attackers often find ingenious ways to bypass it.

My goal is to provide a deep dive into these techniques, sharing real-world examples from my bug bounty hunting journey to help others understand and defend against these attacks.

Understanding Multi-Factor Authentication

Multi-factor authentication is a security mechanism that requires users to verify their identity through multiple layers, typically combining something they know (password), something they have (a device or token), and something they are (biometrics). Despite its robustness, MFA isn't foolproof. Threat actors are continually evolving their methods to bypass even the most advanced authentication systems.

Case 1 — No Rate Limiting on 2FA Code Parameter
P2 · Critical

A common oversight is the lack of rate limiting on the 2FA code parameter, which allows attackers to brute-force one-time passwords. Since 2FA codes are typically 4–6 digits, the absence of attempt limits makes it feasible to guess the correct code within its validity window.

Steps to Reproduce

  1. Log in to the target application with valid credentials and initiate the 2FA process.
  2. Use Burp Suite or OWASP ZAP to capture the request sent to the 2FA verification endpoint (e.g., POST /api/2fa/verify).
  3. Automate submission of multiple requests using Burp Intruder or a custom Python script, cycling through all possible codes (000000–999999).
  4. Observe whether the server allows unlimited attempts within the code's validity period.
Burp Intruder payload config POST /api/2fa/verify HTTP/1.1 Host: redacted.com {"code": "§000000§", "session": "abc123"} → Payload type: Numbers (000000 to 999999, step 1) → No throttling observed after 500+ requests
Report submitted to Bugcrowd
Triager marks submission as Out of Scope
Program owner overrides — changes to Unresolved
Rewarded $XXX
Case 2 — 2FA Bypass via Password Reset Endpoint
P3 · High

This vulnerability exploits a flaw in the password reset flow — the process allows full account access without triggering the SMS-based 2FA code verification, completely bypassing the second factor.

Steps to Reproduce

  1. Log in, enable SMS-based 2FA, then log out.
  2. Set up Burp Suite to monitor HTTP traffic.
  3. Navigate to the password reset page and request a reset link.
  4. Use the reset link to change your password — observe that you are logged in directly without 2FA verification.
Impact: This bypasses the SMS 2FA entirely. Any attacker who gains access to a victim's email (phishing, credential stuffing) can reset the password and log in with no 2FA challenge.
Report submitted
Bugcrowd staff requested additional information + video PoC
Severity changed P4 → P3 after video PoC submitted
Rewarded $XXX
Case 3 — OTP Brute Force via IP Address Rotation
P3 · High

Rate limiting on OTP submissions was enforced at the IP level. By rotating IPs through a VPN or proxy, the rate limit could be completely bypassed, making OTP brute-forcing trivially scalable.

Steps to Reproduce

  1. Visit the password reset page and submit a valid email to trigger an OTP.
  2. Enter incorrect OTPs multiple times until your IP is blocked.
  3. Switch to a new IP via VPN or proxy.
  4. Resume OTP attempts — the counter resets, allowing continued brute-forcing.
  5. Repeat until the correct OTP grants access.
Impact: Attackers with access to dynamic IP services (cheap VPNs, residential proxy pools) can automate this at scale across thousands of accounts. IP-based rate limiting alone is insufficient protection.
Vulnerability reported
Bug validated, severity classified as P4
Initial reward $XXX
Severity escalated to P3 after further discussion
Final reward $XXX issued
Case 4 — 2FA Bypass via Response Manipulation
Duplicate

The server's JSON response included a requires_2fa parameter. By intercepting and modifying the response before it reached the client, the 2FA requirement could be silently disabled.

Steps to Reproduce

  1. Navigate to the login page and enter valid credentials.
  2. Intercept the server's response in Burp Suite.
  3. Modify "requires_2fa":"GoogleAuthenticator" → "requires_2fa":null.
  4. Forward the modified response — login succeeds without 2FA.
Response before / after manipulation // Before {"status":"ok","requires_2fa":"GoogleAuthenticator","user_id":1234} // After (modified in Burp) {"status":"ok","requires_2fa":null,"user_id":1234}
Vulnerability submitted
Marked as duplicate — already reported and in queue
Case 5 — 2FA Bypass via Chrome Extension
Duplicate

The platform's Chrome extension login flow did not enforce 2FA. Logging in through the extension granted full dashboard access without triggering the second factor, even when 2FA was enabled on the account.

Steps to Reproduce

  1. Enable 2FA on your account at redacted.com.
  2. Download and install the platform's Chrome extension.
  3. Click the extension icon and log in with your credentials.
  4. Observe: you are granted full access without any 2FA prompt.
Vulnerability submitted
Marked as duplicate
Case 6 — 2FA Bypass via Temporary Account Lockout
P3 · Medium

After a temporary account lockout due to multiple failed login attempts, the 2FA verification step was dropped upon re-login once the lockout period expired — a misconfiguration in the post-lockout authentication flow.

Steps to Reproduce

  1. Log in, enable 2FA, and log out.
  2. Enter the wrong password 10 times to trigger a 1–2 hour lockout.
  3. Wait for the lockout period to expire.
  4. Log in again with correct credentials — 2FA is not prompted.
Submission validated
Rewarded $XXX + 10 points
Case 7 — 2FA Bypass via Reuse of Pre-2FA Password Reset Link
Duplicate

Password reset links generated before 2FA was enabled were not invalidated when 2FA was activated. Using a stale reset link after enabling 2FA logged the attacker directly into the dashboard without a 2FA challenge.

Steps to Reproduce

  1. Request a password reset link but do not use it.
  2. Enable 2FA on the account.
  3. Log out, then use the previously generated (now stale) reset link.
  4. After resetting the password, you are logged in to the dashboard with no 2FA prompt.
Confirmed as duplicate of a prior submission already addressed
Case 8 — Backup Code Validation Flaw
P3 · Medium

Backup codes generated by the platform failed at the validation layer — an error "Value must be less than or equal to 999999" was thrown, rendering all backup codes permanently unusable for accounts with 2FA enabled.

Steps to Reproduce

  1. Enable 2FA and save the backup codes provided.
  2. Log out and attempt to log in using a backup code.
  3. Observe the error: "Value must be less than or equal to 999999"
  4. No backup code from the generated set works.
Impact: Users who lose access to their 2FA device (lost phone, app deleted) have no recovery path. Backup codes, the safety net of 2FA, are completely broken — leaving users permanently locked out.
Submitted with video PoC after Bugcrowd staff requested additional detail
Validated as legitimate issue
Rewarded $XXX + 5 points
Case 9 — 2FA Skipped on Facebook OAuth Login
P4 · Low

When logging in via Facebook OAuth, the 2FA verification step was entirely skipped — even if 2FA was enabled on the account. An attacker who compromised a victim's Facebook account could use OAuth to access the target platform with no 2FA friction.

Steps to Reproduce

  1. Enable 2FA on your account.
  2. Log out, then log in via "Continue with Facebook".
  3. Observe: you land directly on the dashboard with no 2FA prompt.
Submitted, additional context provided on impact
Classified P4 (low risk) — social login compromise considered higher-order issue
Acknowledged as best-practice recommendation
Rewarded $XXX + 5 points
Case 10 — 2FA Bypass in SPA via Parallel Session Race
P4 · Medium

A race condition in a single-page application allowed bypassing newly-enabled 2FA by exploiting a login session that was partially initiated before 2FA was turned on — across two separate browser instances.

Steps to Reproduce

  1. In Browser 1, navigate to https://redacted.com/vault/.
  2. In Browser 2, open https://redacted.com/vault/beta/ and enter the email — pause at password.
  3. In Browser 1, complete login, go to account settings, and enable 2FA.
  4. Return to Browser 2, complete login by entering the password.
  5. Result: logged in without a 2FA prompt.
Submitted with PoC video, confirmed reproducible across different IPs
Vendor confirmed timeout policy was not active during beta
Issue patched, severity P4
Rewarded $XXX
Case 11 — Full Phone Number Disclosed via Improper XML Response
P2 · High

An unauthenticated attacker with only login credentials could retrieve the victim's full phone number by manipulating the content type of the "Resend Code" request — switching from JSON to XML exposed the phone number in the response payload, even without entering the 2FA code.

Steps to Reproduce

  1. Ensure the victim account has 2FA enabled.
  2. Log in with the victim's credentials — you will be prompted for 2FA.
  3. Click "Resend Code" and intercept the request in Burp Suite.
  4. Change the Content-Type from application/json to application/xml.
  5. The XML response includes the victim's full phone number.
XML response leak (redacted) <response> <status>ok</status> <mfa_phone>+1-555-XXX-XXXX</mfa_phone> <!-- ← full number exposed --> <code_sent>true</code_sent> </response>
Impact: This is a pre-authentication PII leak. Any attacker who knows a victim's email and password can harvest their full phone number — enabling SIM swapping, targeted phishing, and social engineering attacks.
Report submitted to Bugcrowd
Vendor accepted and agreed to fix the issue

Final Thoughts

These case studies underscore the importance of rigorous and continuous security testing, especially in areas often considered "safe" due to widely adopted mechanisms like MFA. As seen throughout this research, even minor oversights — improper response handling, token reuse, or broken session management — can completely undermine otherwise robust security controls.

Responsible disclosure is not just about reporting bugs; it's about contributing to a more secure digital ecosystem for users and organizations alike. Every vulnerability shared and patched strengthens the collective resilience of the internet.

If you're looking for a professional penetration test for your web, mobile, or API applications — reach out to VAPT.PK. You can also find me on X (Twitter) or Medium.

Stay curious, stay ethical — and remember, one well-crafted request can uncover vulnerabilities that others miss.