Host Header Injection

Host Header Injection abuses the fact that many applications trust the Host header (or X-Forwarded-Host) to decide which domain a request belongs to and to build absolute URLs. Since the client controls that header, changing it lets us divert links, emails and redirects to an attacker-controlled domain without touching the application.

The most rewarding vector is password-reset poisoning: many sites build the reset link from the request Host, so if we change it the victim gets an email whose link points at our server and hands us their token when clicked.

POST /reset-password HTTP/1.1
Host: attacker.tld
Content-Type: application/x-www-form-urlencoded

email=victim@company.com

If the back-end ignores Host but honours X-Forwarded-Host, try that (and X-Host, X-Forwarded-Server). Other impacts: reaching internal vhosts or restricted panels by changing the Host, and feeding a cache poisoning when the reflected value gets cached. When the Host ends up in a server-side request it borders on SSRF.

How to detect it. The signature is a request whose Host (or X-Forwarded-Host) does not match the service's real domain, followed by an email or response containing that foreign domain. In logs, Host values that are not among the valid virtual hosts, and reset links generated with a domain other than the canonical one. A spike of /reset requests with a varying Host is suspicious.

Defence. Validate Host against an allow-list of permitted domains and reject the rest; do not use Host/X-Forwarded-Host to build email URLs (use a fixed canonical domain from configuration); and ignore X-Forwarded-* headers unless they come from a trusted proxy. It leans on CRLF injection when headers can also be injected.