How Stale Reset Tokens Led to Full Account Takeover (Even After Changing Email)

My name is Yousef Abdullah, and I'm a cybersecurity researcher. Welcome to my latest write-up! Today, I want to share a story about a subtle yet dangerous logic flaw I recently discovered during a security assessment: Stale Password-Reset Tokens Remaining Active After an Email Change.

If you're passionate about web security, bug bounties, or interested in how account recovery flows can introduce severe account takeover risks, grab your favorite drink ☕, and let me walk you through it!

💡 Understanding the Flaw: What is Stale Token Persistence?

When a user requests a password reset, the server generates a unique, time-sensitive token tied to that account. Normally, users expect that making sensitive account updates — such as changing their email address — will revoke or invalidate any previous session tokens or recovery credentials.

In this scenario, however, the password-reset mechanism validates tokens only against their expiration timestamp or single-use state. It fails to check whether the account's underlying email address or security state changed after the token was issued.

This means a reset link sent to an old, potentially compromised email remains fully functional and can be used to hijack the account even after the user updates their account to a new, secure email address!

🔍 The Discovery: How I Found the Vulnerability

While testing the account management workflow across multiple test accounts, I analyzed what happens to active password-reset requests when an account's email is updated.

Here are the step-by-step reproduction steps for this flaw:

1. Initial State: Sign up for an account associated with Email A.

2. Request Reset: Trigger the "Forgot Password" feature for Email A. A password-reset link containing a unique token is delivered to Email A.

3. Change Email: Before opening or using the reset link, log into the account and navigate to Settings → General → User account. Update the account email from Email A to Email B and save.

4. Redeem Stale Token: Go back to the original email sent to Email A, open the old reset link, and submit a new password.

5. Observation: The application accepts the token without error and confirms the password reset.

6. Account Takeover: Log into the account using Email B and the newly set password—login succeeds seamlessly!

⚠️ The Impact

Why is this vulnerability so critical?

• Full Account Takeover (ATO): If an unauthorized party obtains a previously issued reset link (e.g., via a compromised old inbox, shared device, or abandoned email domain), they can reset the password and gain complete control over the account under its new email.
• False Sense of Security: Users who change their email address specifically to migrate away from an unsafe or compromised mailbox remain completely exposed without realizing it.
• Systemic Nature: Tested and independently confirmed across multiple test accounts, proving it is an underlying logic issue in how tokens are managed rather than an isolated glitch.

🛠️ How to Fix It (Remediation)

To remediate this vulnerability, development teams should implement the following best practices:

• Global Token Invalidation: Automatically revoke and invalidate all outstanding or unused password-reset tokens immediately whenever an account's email address (or any other sensitive credential) is updated.
• Attribute Binding: Bind each password-reset token to the specific email address it was generated for. During token redemption, verify that the token's bound email matches the account's current email address.
• State Verification: Maintain a password_changed_at or credentials_updated_at timestamp on the user record, and reject any reset token issued prior to that timestamp.

🎯 Conclusion

Flaws like stale token persistence highlight why developers must treat sensitive account state changes as global security events. Securing authentication workflows isn't just about validating inputs — it's about ensuring state consistency across the entire lifecycle of an account!

Thank you so much for reading! I hope you found this write-up insightful. Feel free to connect with me if you have any questions or feedback.

Author: Yousef Abdullah

Security Researcher