Password Reset Poisoning (Host Header)

Many apps build the password-reset URL in the email using the incoming request's host — https://<Host>/reset?token=.... If that host comes from an attacker-controllable header, the reset link in the victim's email can point at an attacker's server.

How it works

The attacker submits a "forgot password" request for the victim's account but injects a header such as Host: evil.com or X-Forwarded-Host: evil.com. The application generates a valid reset token for the victim and emails them a link like https://evil.com/reset?token=<victim_token>. When the victim clicks (or when an email scanner/prefetcher fetches the link), the token is delivered to the attacker — who then resets the victim's password.

How to test

Send the reset request with X-Forwarded-Host, X-Host, X-Forwarded-Server, or a dual Host header pointing at a domain you control. Inspect the resulting email (or your server logs) to see whether the link host was poisoned.

Impact

Account takeover via a valid, server-issued reset token — no token guessing required.

Defenses

• Build absolute URLs from a configured, trusted base URL, never from request headers.
• Validate/allow-list the Host header; ignore X-Forwarded-* unless from a trusted proxy.