How I Uncovered an Account Takeover Flaw via Unexpired Reset Tokens

Introduction

Password reset logic is one of the most heavily tested areas in web security. During authentication and identity management testing, standard checks usually cover token randomness, expiration timers, and rate limiting.

However, logic flaws often hide where state transitions overlap specifically, what happens to pre-existing security tokens when an account's primary identity attributes (like email or password) change?

This post walks step-by-step through discovering and exploiting a vulnerability where generated password reset tokens remained active even after changing the primary email address and updating the account password.

The Concept: Token Invalidation Failure

When a user requests a password reset link, the server generates a token tied to that specific account state. In a securely designed application, that token should immediately become invalid if any of the following occur

1. The token is used to reset the password.
2. A new password reset token is requested
3. The user updates their account credentials (password or email) while logged in

If old tokens persist in a active state across email or password changes, an attacker who obtains or holds an old reset link can regain control over the modified account.

Step-by-Step Discovery Walkthrough

Step 1: Pre-generating the Token

1. Create an account registered to john@example.com.
2. Verify the account and log out.
3. Request a password reset for john@example.com.
4. Check the inbox of john@example.com and extract the generated password reset link:

https://example.com/users/password/edit?reset_password_token=EXPIRED_OR_NOT?

5. Crucial step: Do not click or consume the reset link yet. Store it aside.

Step 2: Modifying Account Identity Attributes

1. Log back into the account using the current valid credentials.
2. Navigate to Account Settings and update the email address from john@example.com to teena@example.com.
3. Complete the email verification process sent to teena@example.com.
4. While logged in under the updated profile (teena@example.com), explicitly change the account password.
5. Log out of the account.

Step 3: Triggering the Stale Token

1. Paste the old password reset link (originally sent to john@example.com in Step 1) into the browser.
2. Submit a new password.

Observation:

Instead of throwing an Invalid Token or Token Expired error, the server accepts the token and resets the password for the account now associated with teena@example.com

Impact & Exploit Scenario

• Account Hijacking / Re-entry: If an old email account (john@example.com) is compromised or accessible by a third party, an attacker holding that old reset link can regain access to the user's account long after the user updated their email to a secure address (teena@example.com)
• Broken Session/Token Lifecycle: Changing an email or password implies a trust boundary reset. Existing tokens must be revoked immediately across all notification channels.

Key Takeaways for Bug Hunters

• Test Edge Cases in State Transitions: Don't just test if a token works; test if it continues to work after changing user state (changing email, changing password, revoking sessions).
• Persistence Pays Off: If a triage team marks a logic issue as Informative, provide concrete threat models or revisit similar findings in public disclosures to refine your arguments.