Clarify classification guidance for "Reset token not invalidated after email change" — consider ATO cases #486
Description
Hello VRT maintainers,
I would like to propose a clarification to the taxonomy regarding cases where a password-reset token issued to a previous account email remains valid after the account email is changed.
Problem:
When a stale reset token can be used to change a password and then log in to the account now bound to the new email (end-to-end reproducible), this results in a Full Account Takeover (ATO). Such situations can occur with recycled/shared/compromised mailboxes, token flooding, or forwarded messages, and thus represent a realistic attacker path.
Suggested guidance:
- If a stale reset token allows end-to-end account takeover (reset password → login to account showing new email), classify as High/Critical (P2/P1) depending on exposed data.
- If the finding only shows tokens are not invalidated but no practical path to account access exists, classify as Informational/P5.
Recommended criteria to escalate severity:
- Token accepted regardless of current account email or recipient binding.
- No invalidation of outstanding tokens upon email change.
- Reproducible login after reset.
- Realistic attacker scenarios possible (recycled/shared/compromised mailboxes, token flooding, forwarded messages).
Recommended remediation guidance (for taxonomy notes):
- Invalidate all outstanding reset tokens on email change.
- Bind reset tokens to the recipient email and verify match before accepting.
- Use single-use tokens with short TTLs and rate-limit reset requests.
- Notify both old and new email addresses and require confirmation via the new email for resets after an email change.
This is a taxonomy suggestion only — no target-specific or exploit details are included here. Happy to help draft a PR if the maintainers want proposed wording.
Thanks,
— Malek