How I Found a Bug That Could Let Anyone Hijack Your Account — Without Touching Your Email

Before We Start — What Even Is an Account Takeover?

Imagine you go to sleep with your bank account, your photos, your messages — all safely locked behind your password. You wake up and someone else is inside. They changed your password. You can't get back in.

That's an Account Takeover (ATO). And the scary part? The one I found didn't require hacking, phishing, or even knowing the victim's password. Just one small change to a single word in a web request.

The Vulnerability — Explained Like You're 12

Every app has a "Forgot Password?" button. Here's how it's supposed to work:

1. You enter your email
2. The app sends you a secret reset link
3. You click the link, set a new password
4. Done — and that link only works for your account

The key word there is "only works for your account." The secret link (called a token) should be glued to your identity. The server should check: "Does this token belong to this person? Yes? Okay, proceed."

In this application, that check didn't exist.

What Was Actually Happening Under the Hood

When you submitted a new password through the reset form, the app sent a request to the server that looked something like this:

email=attacker@gmail.com&token=abc123&new_password=NewPass@123

email=attacker@gmail.com&token=abc123&new_password=NewPass@123

Now here's the flaw — the server trusted the email field blindly. It didn't check whether the token abc123 actually belonged to attacker@gmail.com. It just said: "Oh, you want to reset the password for whatever email you typed? Sure, go ahead."

That means if an attacker swapped the email before the request reached the server:

email=victim@gmail.com&token=abc123&new_password=NewPass@123

email=victim@gmail.com&token=abc123&new_password=NewPass@123

The server would happily reset the victim's password. Using the attacker's token.

How I Discovered It — Step by Step

I was doing a security test on the password reset flow when something felt off. Here's exactly what I did:

Step 1: Went to the Forgot Password page and entered my own email address (an account I control).

Step 2: Got the reset email and opened the reset link.

Step 3: Entered a new password — but before clicking Submit, I opened Burp Suite (a tool that lets you intercept and inspect web requests before they're sent).

Step 4: I saw the outgoing request. It contained my email and the reset token.

Step 5: I changed the email field to a different registered user's email address.

Step 6: Forwarded the modified request.

Step 7: Tried logging in with the victim's email and the new password I had set.

It worked. Full access. Zero resistance.

No access to the victim's inbox. No phishing. No social engineering. Just one changed word.

Why This Is Rated Critical

Security researchers rate vulnerabilities on a scale. This one hit Critical — the highest possible rating — for good reason:

No special skills required. Burp Suite is free and widely available. Intercepting a request takes under 2 minutes to learn.

No victim involvement needed. You don't need to trick the victim. You don't need their email password. You don't need access to their device. You just need their email address — which is often publicly visible on LinkedIn, GitHub, or any website they've registered on.

Affects every single user. This isn't a bug that works on one type of account or one configuration. Every registered user was at risk.

Permanent damage. Once an attacker resets your password, you're locked out. You can't even use "Forgot Password" because they'll just do it again.

The Root Cause — What Went Wrong in the Code

The developer made one dangerous assumption: "I'll trust whatever email the user sends me in the request."

In secure applications, the email parameter during password reset should be completely ignored. The reset token alone should tell the server whose password to change — because the token was generated and stored on the server side, tied to a specific account.

Instead, the server was doing something like:

"Token received ✅ — now reset the password for whatever email is in this request.

When it should have been doing:

"Token received ✅ — look up which account this token belongs to, reset THAT account's password, and ignore anything the client tells me about the email."

The client (the user's browser) should never be trusted to tell the server which account to modify. That decision must always live on the server.

How to Fix It — The Right Way

If you're a developer, here's what secure password reset logic looks like:

1. Bind the token to the user at creation time. When you generate a reset token, store it in your database alongside the user's ID. Not their email — their ID.

2. Ignore the email parameter on submission. When the reset form is submitted, look up the token in your database. Find the user tied to that token. Reset that user's password. Throw away whatever email the client sent.

3. Expire tokens after use. Once a reset token is used, delete it. A token that can be used multiple times is a token that can be weaponised.

4. Set a short expiry time. Reset tokens should expire after 15–30 minutes. A token that lives for 24 hours gives an attacker a huge window to operate.

5. Log suspicious activity. Multiple failed resets, resets from unfamiliar IPs, or a high rate of resets should trigger alerts.

The Bigger Lesson for Everyone

This vulnerability is a perfect example of what security researchers call "trusting the client." The client is everything you control as a user — your browser, your app, your intercepted requests. Anything the client sends to the server can be modified.

Secure applications are built on one principle: never trust input from the client without server-side verification.

It doesn't matter how good your front-end validation looks. It doesn't matter if the button is greyed out. If the server doesn't verify, an attacker with Burp Suite will walk right through.

Disclosure

This vulnerability was reported responsibly to the affected organisation through proper disclosure channels before publishing this article. Details about the company, domain, or platform have been intentionally withheld to protect their users while remediation is in progress.

Final Thought

Security isn't just for "big companies" or "important data." Every app that stores a user's email address, message, or photo has a responsibility to protect it. And vulnerabilities like this — hidden in something as routine as "Forgot Password?" — are a reminder that the simplest features deserve the most scrutiny.

If you're a developer, audit your password reset flow today. If you're a user, use apps that take security seriously — and enable two-factor authentication wherever you can.