It was a normal day, me and my bro asherif1 were working on a private program when we stumbled upon something interesting. We were testing the authentication flow nothing fancy, just the usual login and logout cycle. But sometimes, the most interesting bugs hide in the most obvious places.

While testing the application, we noticed it was making standard login API calls. Something caught our attention what if the app was trusting the response a little too much? We fired up Burp Suite and decided to find out.

We logged into our account, then logged out. Simple enough. Then we tried to log back in but this time with the wrong password. The server responded with a 401 Unauthorized. That's expected. But what happens if we change that response to 200 OK?

The app let us in. And not just the UI we were able to perform any sensitive action without any verification. We could change the account's name, email, and password freely, as if we were the original owners.

Root Cause:

The application performs authentication validation only on the client side. After logout, the session is cleared from the client but remains valid on the server for 24 hours. When the response is manipulated to indicate success, the app reuses the cached session without verifying it server-side.

Steps to Reproduce:

Scenario 1

  1. Log in to your account (Account A)
  2. Log out
  3. Attempt to log in with the correct email but a wrong password
  4. Intercept the response — server returns 401 Unauthorized
  5. Modify the response to 200 OK
  6. The application grants access to Account A and you can perform any action like changing name, email, or password without any verification.

Scenario 2

  1. Log in to your account (Account A)
  2. Log out
  3. Attempt to log in with a completely wrong email and password
  4. Intercept the response — server returns 401 Unauthorized
  5. Modify the response to 200 OK
  6. The application still grants access to Account A and you can perform any action like changing name, email, or password without any verification.

Impact

This is where it gets serious. Imagine a shared device scenario:

A user logs into their account at a public device. They finish up, log out, and leave. Simple, right? But here's the problem that session is still alive on the server for 24 hours.

An attacker sitting at the same device can:

  • Attempt login with any random credentials
  • Intercept and modify the 401 response to 200 OK
  • Gain full access to the previous user's account
  • Change their email, password, or any account details
  • Achieve complete Account Takeover without knowing a single credential

This issue was identified and reported in a private program on Bugcrowd, and we were rewarded for this finding.

Thanks for reading!

LinkedIn: KhaledAhmed107

X: KhaledAhmed107

FB: KhaledAhmed107