“Wait… I didn’t even set a new password. How am I inside the account?”

That’s not how it’s supposed to work… right?

But that’s exactly what happened — and it all started with a simple “Forgot Password” link.

What I uncovered was a critical logic flaw in an authentication flow — one that quietly bypassed passwords, ignored MFA, and left every user account exposed to invisible hijack.

It began like any other night of casual security poking.

I was testing the login and password reset functionality of a platform — let’s call it redacted.com to keep things responsible. Everything looked normal on the surface.

• Clicked “Forgot Password”
• Entered a known user email
• Got the reset link via email
• Clicked on it — landed on the “Set New Password” page

So far, all routine.

But I didn’t enter a new password. I just clicked “Cancel”.

Instead of logout i got into dashboard !
The dashboard loaded.
I was inside the account. Authenticated. Full access.

Let me emphasize this:

✅ I didn’t enter a password
✅ I didn’t reset anything
✅ I wasn’t logged in previously
✅ I didn’t pass any MFA
❌ But I still had a valid session

The app had granted me access just by visiting the reset link — even though I never completed the password reset flow.

It was like the system said, “You clicked the link? Good enough — come on in.”

This seemingly small logic oversight has massive implications:

• ⚠️ Account Takeover (ATO): An attacker with access to the reset link can hijack any account — without knowing the password.
• 🚫 Bypass of Authentication & MFA: Clicking the link alone creates a valid session, bypassing any login protection layers.
• 🧑‍💻 Privilege Escalation: Targeting higher-privilege accounts (admins, moderators) could compromise entire systems.
• 📤 Token Leakage Risk: If that reset link leaks via:
• Browser referrer logs
• Third-party integrations (e.g., proxies, plugins)
• …then anyone who gets it can log in — instantly.

And remember: these reset links are often stored in emails for days, sometimes forever.

Let’s break down how this should have worked in a properly secured system.

They receive a reset link in their email, which includes a secure token.

Expected behavior:

• The system validates the token — checks if it’s expired or already used.
• ✅ No session is created yet.
• User is taken to a “Set New Password” page.

• The user enters and confirms a new, strong password.
• The password is securely hashed and updated in the system.
• Then,
• Or redirected to the login page with a “Password updated” message.
• And then logout and redirect to login page !!

✅ This is secure — the user has completed a strong verification action.

• They click “Cancel” or navigate away without setting a password.

Expected behavior:

• No password update.
• No session created.
• The user should be redirected to the login page.
• The token remains valid (temporarily), but cannot create a session without proper use.

🔐 Crucial Rule:

A reset link is not a login shortcut. It’s a permission slip to change your password — nothing more.

Now here’s where it gets even more dangerous.

Imagine this reset link was leaked by accident:

• 📧 Forwarded email thread
• 🧩 Email plugin or extension logs referrer URLs
• 🧠 User clicked the link on a shared or public system
• 🌐 Proxy or monitoring tool stored the request

If any third party got their hands on that reset link, and your system allows sessions to be created instantly from it…

💥 That’s an instant account takeover — no brute force, no phishing, no password guessing.

Just one URL = total control.

The likely root cause? A flawed assumption in logic:

“If the user has the reset link, they must be verified.”

This is where many systems go wrong.

But having the link only means one thing:
The user has access to the inbox.
It doesn’t mean they are ready to be trusted with a valid session.

I never meant to log in.

I clicked a link. I looked around. I clicked “Cancel.”

But somehow… I was already inside.

No password reset. No confirmation. Just… trust.

A reset link is supposed to give users a second chance — not act as a secret entrance for intruders.

Security isn’t just about encryption and firewalls. It’s about timing.
And in this case, the session came far too early.

What if I wasn’t a security researcher? What if I was someone else?