Multi-Factor Authentication Bypass Worth $10K

Introduction :

In August 2025, I was able to bypass the Multi-Factor Authentication (MFA) on the main web application of a widely used video communication company. I reported it to their private bug bounty program on hackerone, where it was triaged as High severity, and I was awarded a $10,000 bounty, which was my highest and first 5 digit payout.

Let’s get into it.

First, let me explain how REDACTED’s MFA worked:

• A user had MFA enabled on the account using either a phone number or an authenticator app.
• The user went to https://redacted.us/signin and logged in with their credentials.
• The application then redirected them to: https://redacted.us/mfa/index?token=%7EUSER_CRYPTO%7EDFdNGXkVy_8eatvHXwAALQAAAPbnL1yW4qeoDtk8ANVXBPvAvk1YtdsWmElq7-uOkv8kQE3PF_coMECfzOtpKmfBFR8UbTAeY8qHRBzo0u0wMDAwMDE&km=true&from=web_login#/mfa/verify

In the URL, you can notice that the application generated a token. This acted as user identifier.

The user then entered the MFA code, and the application sent the following request. For a successful MFA attempt, the request required the cookies, CSRF token, and the token=~USER_CRYPTO~<> value tied to the MFA session.

POST /mfa/verify HTTP/2
Host: redacted.us
Cookie: <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:150.0) Gecko/20100101 Firefox/150.0
Content-Type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest, OWASP CSRFGuard Project
redacted-Csrftoken: KNE6-7FNV-3OWZ-AUUA-HY09-ZBDV-48Y0-V6GM
Content-Length: 227


style=new&token=~USER_CRYPTO~<>&code=111111&mfaType=SMS&keep_me_signin=true&stk=&stype=&url=&src=&from=web_login

• For an unsuccessful MFA attempt, the application returned:

{"status":false,"errorCode":209,"errorMessage":"The verification code you've entered is incorrect.","result":null} 

• For a successful MFA attempt, the application returned:

{"status":true,"errorCode":0,"errorMessage":null,"result":{"redirectUrl":"https://redacted.us/profile"}}

I spent the whole day testing REDACTED’s MFA flow, but I had no luck finding anything.

On the second day, I went back to testing for BAC. I logged into another testing account from the same organization and landed on this page:

In the screenshot, you can see that the application was suggesting that the organization member to set up MFA and the path was same as when the application asks for MFA code with the user token.

I asked myself: What is the need for an user token here if the member hasn’t even enabled MFA on the account?

There was also a Skip button on the page. After clicking the skip button, the application sent the following request:

POST /mfa/skip HTTP/2
Host: redacted.us
Cookie: <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:151.0) Gecko/20100101 Firefox/151.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
X-Requested-With: XMLHttpRequest, XMLHttpRequest, OWASP CSRFGuard Project
Redacted-Csrftoken: ENMV-LKLF-PPST-QON4-4NLT-3EQ8-CNDK-7NS4
Content-Length: 188
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=0
Te: trailers

token=~USER_CRYPTO~DOR_ccttw-ZX1_HLFQAALQAAACZGXZfM8HZZ-hhv8iy2KTXCfbOwPEyGCgw8rGTJehuanW30zrW_EPEBorPeEFDrg1gpeRnj55lzcoSOp80wMDAwMDE&from=web_login&keep_me_signin=true&isPhoneLogin=false

I asked myself again: What is the need for this token in the POST body request if the user hasn’t enabled MFA?

At that point, the hacker logic started running in my mind:

WHAT IF I PERFORM THIS SAME FLOW ON A MFA-ENABLED ACCOUNT BEFORE ENTERING THE MFA CODE?

So the attack flow would be:

• As an attacker, I already had the credentials of a MFA-enabled account.
• I went to https://redacted.us/signin and signed into the victim account.
• The application generated the user token.
• Instead of performing the POST /mfa/verify flow, I performed the POST /mfa/skip flow using the generated token.

Boom. MFA bypassed.

Get farhaan’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Unfortunately, it didn’t happen immediately. The response was:

{"status":false,"errorCode":202,"errorMessage":"Something went wrong. Please refresh this page.","result":null}

So I started playing with the parameters.

If you notice, in the vulnerable POST /mfa/skip request, there was an isPhoneLogin=false parameter.

I simply changed it to true, and the response became:

{"status":true,"errorCode":0,"errorMessage":null,"result":{"redirectUrl":"https://redacted.us/profile"}}

I was like, WHAT?

I couldn’t believe it, so I cleared the browser session and tried exploiting it again.

And yeah, IT WAS WORKING!

I quickly wrote the report that morning and waited for the response from HackerOne. A part of me thought it was probably going to be a duplicate because of how simple it was.

But it got triaged as High severity the same evening.

Steps to Reproduce [NOT REPRODUCIBLE ANYMORE] :

1. Log in to redacted.us using the victim’s credentials.
2. When prompted for the MFA code enter the code and intercept the request in proxy tool.
3. Modify the request endpoint from: POST /mfa/verify to POST /mfa/skip and replace the POST body with:

token=<victim's_token>&from=web_login&keep_me_signin=true&isPhoneLogin=true

4. Forward the request.

5. Observe that the MFA requirement is bypassed, and the attacker gains access to the victim’s account.

It was accepted as High severity by the team according to their own vulnerability calculator.

Timeline

• Report Submitted : August 27, 2025
• Triaged by H1: August 27, 2025
• Bounty Awarded: September 16, 2025
• Vulnerability Marked Resolved: March 30, 2026
• Disclosure Requested : April 23, 2026
• Disclosure Approved: October 21, 2026

Thank you for reading.

If you have any queries, feel free to reach out to me on x.