Host Header Injection: How to Find and Exploit It

Host Header Injection: How to Find and Exploit It

Many apps trust the HTTP Host header (or X-Forwarded-Host) to build absolute URLs — reset links, email links, redirects, and resource paths. If an attacker controls that value and the app reflects it into a security-sensitive URL, the result ranges from poisoned password resets to cache and routing bugs.

The header is attacker-controllable, so treating it as trusted is the mistake you are hunting for.

Where the Host header leaks into logic

• Password-reset and email verification links
• Absolute redirects and canonical URLs
• Loaded scripts, stylesheets, or API base URLs
• Cache keys and virtual-host routing

If any of these are built from Host or X-Forwarded-Host, you have a target.

Testing method

1. Capture a normal request and note where the host appears in responses or emails.
2. Change Host (or add X-Forwarded-Host) to a value you control, keeping everything else identical.
3. Observe whether links, redirects, or resource URLs now point at your domain.
4. Try duplicate host headers, an added X-Forwarded-Host, and absolute request lines if the stack allows.

Use a domain you own as the injected host so any callback clearly belongs to you.

Password-reset poisoning (safest high-impact proof)

The classic impact:

1. Request a password reset for your own test account.
2. Inject your controlled host into the request.
3. If the reset email now contains a link pointing to your domain, the token would be delivered to an attacker in a real scenario.

Prove it end to end with your own account — never trigger resets for other users to “demonstrate” token theft.

Other impacts

• Cache poisoning: if the reflected host is unkeyed and cached, others receive the poisoned response (test on an isolated cache buster).
• Open redirect / SSRF-adjacent routing: host-based routing that reaches internal vhosts.
• Web link hijacking: any emailed or displayed absolute URL built from the host.

Common false positives

• Host reflected only in an error page with no security effect
• A strict allowlist that rejects unknown hosts (you'll see a 400 or default vhost)
• Redirects that ignore the header and use a fixed base URL

Report structure

Show the injected header, the reflected sensitive URL (reset link, redirect, or cached response), and the concrete impact using your own account. Recommend a strict host allowlist, ignoring X-Forwarded-Host unless from a trusted proxy, and building URLs from server-side config rather than the request.

Defensive checklist

• Validate Host against an allowlist of known domains.
• Build absolute URLs from configured values, not request headers.
• Strip or verify X-Forwarded-* at the edge.
• Bind reset tokens to the account and keep links host-independent.
• Add tests that send forged host headers to reset and redirect flows.

Host header injection rewards hunters who question trusted-by-default inputs. Follow the header into a reset email or a cached response and you'll turn a “low” into a real account-takeover chain.

Original Bugflare guide informed by PortSwigger Host header attack material.