HTTP Host header attacks

The counter-intuitive point to grasp: Host is user input, even though it looks like part of the infrastructure. Developers treat Host as "my domain" because in a normal browser it is — but curl -H "Host: evil" changes it in a second, and the server still processes the request.

The two largest outcomes, both from using Host to build something:

• Password-reset poisoning. If the code builds the reset link with $"https://{Request.Host}/reset?token=...", the attacker sends Host: evil.example, and the victim gets an email with a link to evil.example — clicking it sends the reset token to the attacker. Account takeover, and it sits in exactly the reset flow the authentication topic warns nobody looks at.
• Cache poisoning. If Host (or X-Forwarded-Host) is reflected into a response and the response is cached, one malicious request makes every subsequent user receive the poisoned response (see the web-cache-poisoning topic).

And X-Forwarded-Host is its own trap: teams add it to support a reverse proxy, then trust it — but if the proxy does not reset it, the client can send X-Forwarded-Host: evil, and many frameworks prefer that header over Host.

The mechanism: a request arrives with a client-controlled Host, and the application uses it somewhere sensitive instead of a configured value.

flowchart TD    A["Attacker sends:<br/>POST /password-reset<br/>Host: evil.example<br/>email=victim@acme.com"] --> S{How does the app use Host?}    S -->|"Builds the link from Request.Host"| P["Link: https://evil.example/reset?token=..."]    P --> M["Email to the VICTIM with that link"]    M --> V["Victim clicks → token goes to evil.example"]    V --> X["🔓 Account takeover"]    S -->|"Uses the CONFIGURED domain"| G["Link: https://app.example/reset?token=...<br/>the malicious Host is ignored"]

The key point: the malicious value reaches the VICTIM, it does not stay with the attacker. The attacker sends the request with the victim's email, but the poisoned link lands in the victim's inbox — so this is an attack on someone else, like CSRF and request smuggling.

A table of exploits and the relevant header:

The last row is the common trap: an app checks Host correctly, but its framework prefers X-Forwarded-Host (to support a proxy), and the client can send that header directly — so the Host check is bypassed. This is why the fix must decide explicitly which proxy to trust and which of its headers.

A password-reset flow builds the link from Host — and Host is user input.

# The attacker sends a reset request with the VICTIM's email but their own Host.POST /api/password-reset HTTP/1.1Host: evil.exampleContent-Type: application/json {"email":"victim@acme.com"}

# The email lands in the VICTIM inbox, with a link built from the malicious Host:Click to reset your password: https://evil.example/reset?token=a1b2c3...# The victim clicks (the link looks legitimate, from the app's real email), and the# reset token goes to the attacker's server. Account takeover without a password.

# X-Forwarded-Host variant: the app checks Host correctly, but the framework prefers this header.POST /api/password-reset HTTP/1.1Host: app.example                    ← correct, passes the checkX-Forwarded-Host: evil.example       ← but the framework uses this to build the link {"email":"victim@acme.com"}

# Cache poisoning: Host is reflected into a response and the response is cached.GET / HTTP/1.1Host: evil.example HTTP/1.1 200 OK<link rel="canonical" href="https://evil.example/">   ← reflected, and cached# Every subsequent user gets a page linking to evil.example (see the web-cache-poisoning topic).

# After the fix: the link is built from the CONFIGURED domain, not Host. The malicious Host is ignored.

Password-reset poisoning (many bug bounty reports, ~2016–present). The recurring pattern is almost always the same: the reset flow builds the link from Host (or X-Forwarded-Host), so a request with the attacker's Host sends the reset token to their domain. Memorable because it is a complete account takeover in a single request, and it sits in exactly the reset flow the authentication topic warns is under-reviewed.

James Kettle's research — "Practical HTTP Host header attacks" (2013) and "Cracking the lens" (2017). Defined the class and showed Host/X-Forwarded-Host reaching surprising places: password reset, the cache key, even SQL and templates when Host is logged or stored. It is the source of the exploit table in block 3.

Host-routing CVEs in reverse proxies and frameworks. Several cases where an app uses Host to select a tenant or backend, so a forged Host routes the request to an internal resource — a form of SSRF (the ssrf topic) via a header. It illustrates block 2's point: Host is input, and routing on input is dangerous.

1. Test password reset with a forged Host — the direct poisoning check:

B=https://staging.example.com# Send a reset with the attacker's Host, then check the link in the email.curl -s -X POST "$B/api/password-reset" -H 'Host: evil.example' \  -H 'Content-Type: application/json' -d '{"email":"test@acme.com"}'# The link in the email MUST point at app.example, NOT evil.example.

2. Test the X-Forwarded-Host variant — the common trap. Send a correct Host: app.example but X-Forwarded-Host: evil.example and assert the link still points at app.example. See the csharp / test tab.

3. Grep for using Host to build URLs:

grep -rnE 'Request\.Host|X-Forwarded-Host|HttpContext.*\.Host' --include='*.cs' src/ \  | grep -viE 'HostFiltering|ForwardedHeaders' \  && echo "WARNING: possibly using Host to build URLs — review each site"

4. Check host filtering is on, not *:

grep -rn 'AllowedHosts' src/ appsettings*.json \  | grep -q '"\*"' && { echo "AllowedHosts is * — every Host is accepted"; exit 1; }exit 0# And test directly: an unknown Host must be 400.curl -s -o /dev/null -w '%{http_code}\n' "$B/" -H 'Host: evil.example'   # must be 400

5. Check X-Forwarded-Host from the client is ignored:

# Send directly (not through a trusted proxy) → the framework must NOT use it.curl -si "$B/" -H 'Host: app.example' -H 'X-Forwarded-Host: evil.example' \  | grep -i 'evil.example' && { echo "X-Forwarded-Host from the client is trusted"; exit 1; }exit 0

The perception mistake, and it is the central one: treating Host as a trusted part of the infrastructure. It is a client-sent header, changed freely with one line of curl. Every place that uses Host as though it were your domain is a waiting vulnerability.

The scoping mistake: fixing the reset flow and stopping. The same untrusted Host also reaches canonical URLs, absolute redirects, other emails, and the cache key. The way to find it is to grep every use of Host, not only the reset flow.