Post cover image

February 11, 2026

2FA bypass after fix via manually injecting “isVerifyAuth” cookie in local storage

Hello Hackers 👋

Mahmoud Magdy

2 min read

Hello Hackers 👋

Back again and this time it's even crazier.

⚠️ Before reading this writeup, you MUST read the original report first: https://medium.com/legionhunters/2fa-bypass-via-local-storage-isverifyauth-cookie-manipulation-7d1603f81f6d

Because after the first vulnerability was resolved… I found a new bypass that brings the same 2FA issue back again but in a different way.

This time, I bypassed 2FA without intercepting OTPs, and without entering any OTP at all.

The trick? A cookie called isVerifyAuth… even after it was "removed" in the fix.

🔍 The Scenario

After entering valid login credentials, the application redirects the user to the OTP verification screen at:

example.com/customer/verify-otp

At first, I checked DevTools again to see if the old cookie

isVerifyAuth : false still exists or not.

And yes the company removed it from local storage as part of the fix.

So technically, the cookie was no longer present by default.

None

But the problem was… the application still trusted it if it existed.

🍪 The Discovery

At first, I thought the issue was fully fixed — because the cookie was no longer present in local storage.

But then I asked myself a simple question:

What if the application is still checking this cookie in the code… but only when it exists?

So I manually created the cookie again inside DevTools:

isVerifyAuth = true

After that, I changed the URL manually to:

example.com/customer/profile

And then… BOOM 💥 Access granted again.

No OTP. No server validation. Just manually injecting a cookie that the app still trusts.

⚠️ What Went Wrong?

The application's fix only removed the cookie from local storage.

But the backend logic was still designed to trust the cookie value if it exists.

That means an attacker can simply recreate the cookie manually and bypass 2FA.

So the vulnerability still exists — it was just hidden from normal users.

🧪 Exploitation Steps

  1. Login with valid email and password
  2. You will be redirected to: example.com/customer/verify-otp
  3. Open DevTools → Application → Local Storage
  4. Manually create a cookie named: isVerifyAuth : true
  5. Change the URL to: example.com/customer/profile
  6. Done — access granted without OTP

🔐 Impact

  • 2FA is completely bypassed
  • Attackers can access accounts with only username/password
  • Fix was incomplete, so the same security risk remains
  • High risk of account takeover

🛠️ Suggested Fix

  • Never store 2FA verification state client-side
  • Store 2FA status inside the server-side session only
  • Ignore any client-supplied "2FA passed" flags

Report

I submitted this issue as: 2FA bypass via manual injection of "isVerifyAuth" cookie (post-fix bypass)

None

Alhamdulillah, report accepted ✅

Connect With Me

Thanks for reading, and stay safe out there 🛡️