Password Reset Token Predictable From Email

A password reset endpoint can become a serious security issue when the reset token is predictable.
In this case, the reset token was not random. It matched the SHA-256 hash of the account's email address, which means anyone who knows the email address can calculate the token without accessing the victim's inbox.

🔎 How I confirmed the issue
I verified the behavior in two ways:

1. I performed a legitimate password reset on one of my own accounts.
2. I compared the token received by email with the SHA-256 hash of the account email address.

The values matched exactly.

I then tested the same behavior on another account that I controlled. Without opening the reset email, I calculated the expected token from the account's email address and used it to complete the password reset.
After setting a new password, I was able to log in successfully and obtain an authenticated session with administrator-level privileges.
⚠️ The authenticated session also exposed sensitive information, including secrets contained in a partner-related object.

---

Why This Is a Security Problem​

A password reset token should normally be an unpredictable, single-use secret.
Using a deterministic value such as: SHA256(email)
creates a direct relationship between publicly known account information and the credential-reset mechanism.
An attacker who knows the target email address may therefore be able to generate the expected reset token without accessing the victim's email account.
The risk becomes significantly higher when the affected account has elevated privileges or access to sensitive data.

---

The Scope Question​

The main uncertainty is related to the bug bounty program's scope.
The vulnerable password-reset endpoint itself is not explicitly listed in the program's scope. However, the account affected by the password reset is connected to another asset that is explicitly in scope.
That in-scope asset was accessible through the program's official registration flow.

This creates an important distinction between:

• The location of the vulnerable endpoint.
• The account affected by the vulnerability.
• The final impact of exploiting the vulnerability.
• The asset or functionality where that impact occurs.

🧩 In this case, the vulnerable endpoint appears to be outside the explicitly listed scope, while the resulting account takeover reaches an asset that is within scope.

---

What I Included in the Report​

The report should clearly document the complete attack chain rather than focusing only on the token-generation flaw.
A useful structure is:

1. Explain how the password reset token was generated.
2. Show that the token matches SHA256(email).
3. Explain that the token can be calculated without access to the reset email.
4. Demonstrate the password reset using an account you control.
5. Explain the resulting authenticated session and privilege level.
6. Document the sensitive data that became accessible.
7. Clearly identify which endpoint is outside the listed scope.
8. Clearly identify the in-scope asset reached through the exploitation chain.

For evidence, use only accounts and assets you are authorized to test, and avoid accessing or exposing unnecessary sensitive information.

---

Will a Report Like This Be Accepted?​

There is no universal rule for how triagers handle an out-of-scope entry point that produces an impact on an in-scope asset.
Programs can define scope differently. Some may evaluate the complete attack chain and impact, while others may reject vulnerabilities when the affected endpoint itself is outside the stated scope.
Because of that, the strongest approach is to make the scope relationship explicit in the report and let the program determine whether the complete chain falls within its rules.
💡 If you already submitted the report, you generally do not need to create a second report just because you are concerned about scope. If you have additional evidence that materially clarifies the attack path or the relationship between the vulnerable endpoint and the in-scope asset, add it as a report update.

---

Key Takeaway​

The important technical finding is that the password reset token is predictable because it is derived directly from the account email:

SHA256(email)

That defeats the unpredictability normally expected from a password reset token.
The separate scope question depends on the specific bug bounty program's published rules and how that program defines in-scope assets, vulnerabilities, and attack chains.
🙆🏻‍♂️ If the report already contains the complete technical chain and clearly explains the scope relationship, the next step is usually to wait for the triager's determination rather than submitting the same vulnerability again.