While I was hunting on a target, I came across an acquisition related to it, so I decided to look around the new domain. It immediately caught my eye because it was an e-commerce application with registration and login functionality.
My approach was to first browse the application like a normal user while keeping Burp Suite running to observe the requests and responses. I created an account, completed email verification, and explored the various functionalities inside.
That’s when I found a critical vulnerability, the password reset token was exposed directly in the API response, which could easily lead to a full account takeover.
What’s the flow of password reset functionality? #
A password reset is the process that lets a user set a new password when they forget their old one (or want to change it for security reasons).
In most applications, the flow looks like this:
- User clicks “Forgot Password”.
- The app asks for their email/username.
- The app generates a reset token (a long, random string).
- That token is sent only to the user’s email in a special link.
- The user clicks the link → enters a new password → done.
The key point is that the reset token is like a temporary master key. If someone else gets it, they can take over the account without knowing the old password, as it’s a unique key and is generated for a particular user only, the server trusts it and reset the password for THAT user.
Finding the Vulnerability: Exposed Reset Token #
So, after clicking on the password reset button, I entered my email in the password reset form and captured the request in Burp Suite. Nothing unusual showed up in the request itself, it was just a simple POST to trigger the reset. But when I captured the response to that request, things got interesting. Instead of returning only a success message (like “Password reset link sent to your email”), the API response contained the actual reset token in plain text.
This meant I didn’t even need access to the victim’s email. With the token exposed directly in the response body, I could simply grab it, craft the reset URL, and reset the account password without the user ever knowing.
Press enter or click to view image in full size
From the screenshot, you can notice the reset_token parameter and its value in the body of the response, i was like WTF, cause i only heard about it before and this was my first time actually seeing this bug lol.
So i simply have to craft the request which looked like this:
https://www.example.com/on/uwu.store/Site-example/default/Account-SetNewPassword?token=8dd88d542c6119c40982514c727aa598221b308191337b&utm_source=campaign&utm_medium=email&utm_campaign=example+-+Password+Reset+-V2-PM&utm_term=ResetPassword&utm_id=51297&sfmc_id=22941159
So i opened this crafted link in incognito mode and there i got the the UI to enter new password
Once I clicked on save, it redirected me back to the login page, where I could simply enter the email and the new password to log in successfully.
What’s the impact? #
This vulnerability posed a critical risk to user security, as it allowed an attacker to take over any account without needing access to the victim’s email. By simply triggering a password reset request and capturing the response, the attacker could obtain the reset token in plain text, craft the reset URL, and set a new password. This opened the door to full account takeover, exposing sensitive personal information, enabling identity theft or financial fraud in the case of e-commerce accounts, and ultimately damaging user trust and the platform’s reputation.
Reporting the Bug on HackerOne #
Once I confirmed the vulnerability, I submitted it on HackerOne with all the details, including steps to reproduce, screenshots, and the potential impact. A few days later, the triage team reviewed my report and marked it as a duplicate, which meant someone else had already reported the same issue earlier.
Although it didn’t result in a bounty, it was still a valuable learning experience, especially the importance of testing common functionalities like Forgot Password, since they often hide high-impact bugs.
How to Fix It? #
The reset token should never be exposed in the API response. Instead, it must be generated server-side and delivered only via the user’s registered email. This ensures that only the account owner can access the token and reset their password securely.
Also, i created a video on how you can write bug bounty reports that increase your chances of getting paid! Check it out here:
Final Thoughts #
Even though this report was marked as a duplicate, the experience reinforced why testing authentication and password reset flows is always worth it. These features are critical for user security, and a small misconfiguration can lead to full account takeover. Every duplicate teaches something new, and each finding sharpens the skills needed for the next hunt.
Follow me on X for more updates: medusa_0xf
See ya!