Host Header Injection: One Header, Five Different Bugs

The Host header is attacker-controlled, and yet a shocking amount of application logic trusts it as if it were the app's own identity. That single misplaced trust spawns a whole family of bugs: password reset poisoning, web cache poisoning, authentication bypass, routing-based SSRF, and link poisoning in every email the app sends. This post is the map — one header, five exploits, and how to figure out which one applies.

Why the Host header is dangerous

When your browser requests a page, it tells the server which host it wants via the Host header. But you set that header — it's part of your request, fully under your control. Apps get into trouble when they use Host (or X-Forwarded-Host) to build absolute URLs, decide routing, or make trust decisions. Since you control the value, you control those downstream behaviors.

Step 1: The knobs you can turn

When testing, rotate through these — different stacks trust different ones:

Host: evil.com
X-Forwarded-Host: evil.com
X-Host: evil.com
X-Forwarded-Server: evil.com
X-Original-Host: evil.com

Host: evil.com
X-Forwarded-Host: evil.com
X-Host: evil.com
X-Forwarded-Server: evil.com
X-Original-Host: evil.com

Duplicate Host headers (some servers use the second), and an absolute URI in the request line (GET <https://target.com/> HTTP/1.1 with a different Host) are also worth trying. The single best detection question: does the host I send show up anywhere in the response — the body, a redirect Location, or a link?

The five exploits

A — Password reset poisoning. If the reset link in the email is built from the Host header, set it to evil.com and the victim's reset token walks to your server. Full account takeover. (This has its own deep-dive post in the series.)

B — Web cache poisoning. If the poisoned host is reflected into the response and the response is cached, every subsequent visitor gets your poisoned copy — e.g. a <script src> pointing at your domain = stored XSS for everyone. (Also its own post.)

C — Authentication bypass. Some apps gate admin/internal features by host: Host: localhost, Host: internal-admin, or an internal hostname can flip the app into "trusted internal request" mode and expose panels or endpoints meant only for internal traffic.

D — Routing-based SSRF. In some architectures the Host header steers where the front proxy routes the request. Point it at an internal service or 169.254.169.254 and the infrastructure itself does the SSRF for you.

E — Link poisoning in any email. Not just resets — invites, email verification, "someone mentioned you," and notification emails all often build links from the host. Poison it and every one of those lands the victim on your domain with their token/context.

Step 2: Detect, then match the exploit

1. Send a request with a poisoned Host/X-Forwarded-Host and a unique canary value.
2. Grep the response body, the Location header, and — for flows like reset — the resulting email.
3. Where the canary appears tells you which exploit fits: in a reset email → A; cached + reflected → B; behavior change/unlocked content → C; internal response → D; in any email link → E.

Param Miner (Burp) automates discovering which unkeyed/host-style headers the app reflects — run its header guessing to find hidden ones.

The impact ladder

• Host reflected in body only, no security use → low
• Reflected into a cached response → medium/high (cache poisoning)
• Reset/verification link poisoning → account takeover → high/critical
• Auth bypass / routing SSRF to internal → high/critical

Conclusion — the Host-header playbook

• The Host header is attacker-controlled — apps that trust it are exploitable.
• Rotate Host, X-Forwarded-Host, dupes, absolute-URI request line.
• Detect: does your canary host appear in body / redirect / email?
• Match the exploit: reset poisoning, cache poisoning, auth bypass, routing SSRF, link poisoning.
• Automate discovery with Param Miner.

If you Love reading my blogs. Check my Youtube Channel too.