Password Reset Flaws

The password-reset flow is a favourite target: it exists precisely to let someone who has lost access regain it, so any weakness in it is a path to taking over an account. The bugs are rarely in the cryptography of the token — they are in how the link is built, where the token travels, and whether it is tied to the right account.

What is the vulnerability?

• Host-header poisoning. The emailed link is built from the request’s Host (or X-Forwarded-Host). An attacker sets it to their own domain, so the victim’s token lands on the attacker’s site.
• Token in the response. A debugging leftover returns the reset token in the API response, so anyone who asks for a reset reads the secret directly.
• Token not bound to the account. The server checks the token is valid but not that it was issued for the account being reset, so a token you requested for yourself resets anyone.

Why does it happen?

Each step trusts something it should not: the Host header as a safe base for links, the response as a private channel, a token as proof of identity without binding it to one. The flow “works” in testing because the honest user never probes these seams.

How do you stop it?

Build links from a fixed, server-configured host. Send the token only over the email channel and never in a response. Bind each token to its account id and verify the match — and make tokens single-use and short-lived.

The three labs below walk this: poison the host, read a leaked token, and reset admin with a token issued for guest.