2FA Bypass via Switching Between Email OTP and TOTP During Authentication

Back again with another interesting authentication flaw that resulted in a complete Two-Factor Authentication bypass.

This vulnerability existed because the application allowed users to change their 2FA method during the authentication challenge without verifying the currently configured second factor.

As a result, anyone who already knew a victim's email and password could replace the victim's second factor and log in without ever proving possession of the original one.

🔍 The Scenario

The application enabled 2FA by default for every account.

Users could configure one of two authentication methods:

• Email OTP
• Microsoft/Google Authenticator (TOTP)

After entering valid credentials, users were redirected to:

/customer/verify-otp/

/customer/verify-otp/

where they were expected to complete the configured second factor.

At first glance, everything looked secure.

But while testing the authentication flow, I noticed something unusual…

The application allowed switching between Email OTP and Authenticator (TOTP) directly from the verification page.

No confirmation. No verification of the existing second factor.

That immediately raised a question:

What happens if I change the authentication method before proving ownership of the current one?

🧪 Scenario 1 : Victim Uses Email OTP

Assume the attacker already knows the victim's email address and password.

After logging in, the application requests the Email OTP.

The attacker obviously cannot access the victim's inbox.

Instead of entering the OTP, the attacker simply clicks:

Not able to validate? Try with Microsoft/Google Authenticator

The application immediately generates a brand-new QR code.

The attacker scans it using an authenticator application.

Generates the first TOTP.

Submits it.

And… login succeeds.

No Email OTP was ever verified.

🧪 Scenario 2 : Victim Uses TOTP

The second scenario was just as interesting.

If the victim already configured Microsoft/Google Authenticator, the login page initially requests a TOTP code.

Without providing one, the attacker switches the authentication method to Email OTP.

Then starts the login process again.

Once the OTP page appears, the attacker switches back to TOTP.

The application generates another fresh QR code.

The attacker scans it.

Generates a valid TOTP.

Successfully completes authentication.

Again…

No verification of the victim's original authenticator was required.

⚠️ What Went Wrong?

The application allowed the active 2FA method to be changed during an ongoing authentication challenge without first verifying the user's currently configured second factor.

As a result, an attacker who already possessed valid credentials could replace the victim's existing authentication method with a new TOTP device under their control. Since the application immediately accepted the newly enrolled authenticator, the attacker was able to complete the login process without proving possession of the victim's original Email OTP or TOTP.

In other words, the authentication flow permitted modification of the second factor before the existing one had been validated, effectively undermining the security guarantees provided by Two-Factor Authentication.

🧪 Exploitation Steps

1. Log in with valid credentials.
2. Reach the OTP verification page.
3. Switch the authentication method to TOTP.
4. Scan the newly generated QR code.
5. Generate a valid TOTP.
6. Submit the code.
7. Login succeeds without verifying the victim's original second factor.

🔐 Impact

An attacker with valid credentials could:

• Bypass Email OTP completely.
• Replace the victim's configured TOTP.
• Register their own authenticator.
• Complete login successfully.
• Fully take over the victim's account.

This completely defeated the protection provided by Two-Factor Authentication.

🛠️ Suggested Fix

Changing the authentication method should never be allowed until the currently configured second factor has been successfully verified.

Additionally:

• Require successful verification of the existing 2FA method before allowing any changes.
• Treat 2FA enrollment as a privileged operation.
• Prevent generating new QR codes during an active authentication challenge unless the current factor has already been validated.

📄 Report

I submitted this issue as :

Authentication Bypass via 2FA Method Change During OTP Challenge

Alhamdulillah, another report accepted ✅

Connect With Me

LinkedIn: https://www.linkedin.com/in/mahmoud-magdy-0a8078269/

Email: mahmoudmagdy45456@gmail.com

Thanks for reading, and stay safe out there 🛡️