Let me set the scene.
It’s 2 AM. I’m on my fourth cup of coffee. My Burp Suite has so many tabs open it’s basically a fire hazard. And I’m staring at a login page that looks — completely normal.
Spoiler: it was not normal.
This is the story of how I accidentally broke authentication for an entire platform, reported it responsibly, and got paid more than my dad made in his first job.
No cap.
The Target
I’m not naming the domain. Let’s call it redacted.com — a mid-to-large SaaS platform that handles, among other things, user billing and account management.
You know the type. Clean UI. “Enterprise-grade security” on the homepage. A padlock icon in the footer that they definitely added to make investors feel better.
I’d been hunting on this program for about three weeks. Found nothing. Submitted one informational finding that got closed with the energy of a passive-aggressive coworker saying “noted.”
Then one evening, I noticed something.
The Discovery: Or, “Wait, That Can’t Be Right”
I was going through the password reset flow — not because I expected anything, just because I was bored and reset flows are historically where bad decisions go to retire.
The flow was standard:
- Enter email
- Receive token via email
- Submit token + new password
- Get redirected to dashboard
Boring. Textbook. Fine.
Except.
I noticed the token in the reset URL was exactly 8 characters long. Alphanumeric. No expiry header in the response. And when I checked the request timing — the token wasn’t being validated server-side before the password change went through.
I stared at that for a solid thirty seconds.
Then I tried something stupid.
I intercepted the password reset request and replaced the token with eight random characters.
The password changed.
I sat back in my chair. Looked at my coffee. Looked back at the screen. Looked at my coffee again.
The password changed.
Going Deeper: From “Interesting” to “Oh No”
At this point I should’ve stopped and written the report. But I’m me, so I kept pulling the thread.
The token wasn’t just weak — it was not being checked at all. The server was accepting any 8-character string as a valid reset token, as long as the email address in the request matched a real account.
Which means:
- I know your email (not hard — have you seen LinkedIn?)
- I trigger a password reset for your account
- I intercept or replay the request with any garbage token
- I set your password to whatever I want
- I log in as you
Full account takeover. No interaction required from the victim. No phishing. No malware. Just me, a proxy, and a token that was essentially a participation trophy.
The kicker? The email with the real token still gets sent to the victim. So they’d get a reset email they never asked for, probably think it was spam, and move on with their life — completely unaware that I now own their account.
Testing Scope: How Bad Was It Really?
I needed to understand the blast radius before reporting.
So I created three test accounts with email addresses I controlled, and ran the attack against all three. Clean. Every time. No rate limiting. No CAPTCHA. No anomaly detection. Nothing.
I also checked if admin accounts were in scope. They were.
I tested one of the admin test accounts provided by the program.
Full admin access. In about forty-five seconds.
At this point I closed Burp Suite, made another coffee, and wrote the report with the calm, measured energy of someone who is absolutely not internally screaming.
The Report
I structured it like this:
Title: Authentication Bypass via Non-Validated Password Reset Token Leading to Full Account Takeover
Severity: Critical
Impact: Complete account takeover for any user on the platform, including administrative accounts. No prior authentication or user interaction required.
Steps to Reproduce:
- Register or identify a target account by email
- Trigger the password reset flow for that email
- Intercept the outgoing reset request
- Replace the token parameter with any 8-character alphanumeric string
- Submit the request with the new desired password
- Log in with the target email and newly set password
Supporting Evidence: Screen recordings, HTTP request/response pairs, proof-of-concept for three separate accounts including the provided admin test account.
I submitted it. Marked Critical. And then I waited.
Triage: The Slowest Twenty-Four Hours of My Life
Bug bounty triage is a unique form of psychological torture.
You know the bug is real. You have the video. You have the requests. You have everything short of a signed confession from their authentication system.
But you still refresh your email every eleven minutes like a golden retriever waiting for their owner to come home.
Nineteen hours later: “Triaged. Marked Critical. Forwarding to engineering.”
I did a fist pump in my room alone like a complete lunatic.
The Fix (And What They Got Wrong the First Time)
Three days later, they pushed a patch.
I was asked to retest.
The fix? They added token expiry — ten minutes. But they still weren’t validating the token value server-side. Just the expiry timestamp.
So the bypass still worked. You just had to do it within ten minutes.
I wrote back politely. Explained the issue. Included a new PoC video where I exploited it in under sixty seconds.
They patched it again. Properly this time. Server-side token lookup, single-use invalidation, rate limiting on the endpoint, the whole thing.
Retest passed. Bug closed. Bounty issued.
Bounty: $$$$
What I Actually Learned
Token validation is not optional.
You would be shocked — genuinely shocked — how many applications implement the delivery of a reset token perfectly and then forget to actually check it on the receiving end. The token becomes decorative. A security prop.
It’s like putting a lock on your door and leaving the key permanently in it.
Rate limiting is not security.
Even if they’d had rate limiting on this endpoint, the attack would’ve worked. Eight characters of alphanumeric is a small enough space that with no lockout, it’s trivially brute-forceable anyway. Proper token generation and server-side validation are not optional extras.
The boring flows have the good bugs.
Login, reset, register. Everyone tests the fancy GraphQL endpoints and the multi-step checkout flows. Nobody reads the password reset RFC and asks whether anyone actually implemented it correctly.
The boring stuff is where the real money is.
Closing Thought
I still use redacted.com as a user. My account is presumably now secured.
I like to think the engineer who wrote that authentication code has since moved into project management.
No shade.
Just: some things are better delegated.
This vulnerability was reported through the official bug bounty program and has been fully remediated. All testing was conducted on accounts I controlled or test accounts provided by the program. The domain has been redacted per responsible disclosure norms.