Day 25 Bug Bounty — Host Header Injection Attacks 2026

CRLF injection on Day 24 showed how injecting newlines into HTTP headers breaks response parsing. Today’s vulnerability is different — I’m not injecting into a header value, I’m replacing an entire header the application trusts. The HTTP Host header is supposed to identify which virtual host the request is for. When applications use it to build URLs, generate emails, or route requests, trusting it without validation creates an injection point attackers control completely.

How Host Header Injection Works

The HTTP Host header identifies which domain a request is intended for. In a virtual hosting environment where multiple domains share an IP, it’s how the server knows which application to serve. Legitimate use: you request https://example.com, your browser sends Host: example.com, the server routes to the right application.

The vulnerability emerges when applications use the Host header value to generate output without validating it against an allowlist. The most common patterns: building absolute URLs for password resets, email confirmation links, and invitation emails; constructing redirect URLs; generating canonical URLs for SEO; and building API endpoint URLs. In each case, if I control the Host header, I control part of the generated URL.

Password Reset Poisoning — The Account Takeover Chain

Password reset poisoning is the complete account takeover attack chain that makes Host header injection a high/critical severity finding. The attack works in three phases: I send a password reset request for the victim’s account with my domain in the Host header, the application emails the victim a reset link containing my domain, and when the victim clicks the link my server receives the reset token.

The critical prerequisite is that the application builds the reset URL using the Host header rather than a hardcoded domain from configuration. Applications that do this are often legacy systems or custom-built platforms where developers assumed the Host header is always the legitimate domain. In Burp Suite, I test this systematically:

X-Forwarded-Host and Override Header Bypasses

Some applications validate the Host header against an allowlist of permitted domains — so injecting an arbitrary Host value fails. But many of these same applications trust proxy override headers like X-Forwarded-Host without the same validation. The logic: “X-Forwarded-Host is set by our trusted reverse proxy, so it must be legitimate.” The problem: HTTP headers are client-controlled, not proxy-controlled. Attackers can set them directly.

My testing order for Host header injection always includes all the override headers. I test them individually because different applications trust different combinations:

Web Cache Poisoning via Host Header

Web cache poisoning via Host header is rarer but significantly higher severity than password reset poisoning alone. When the application caches responses and the Host header value appears in the cached response, injecting a malicious value into the cache poisons the response for all subsequent users who receive the cached version.

The classic scenario: an application reflects the Host header in an absolute URL in a script import or redirect response. If that response is cached (by a CDN, reverse proxy, or application cache), every user who requests the page in the next cache TTL period receives a response with an attacker-controlled domain in the script source — enabling JavaScript injection at scale.

Finding HHI in Bug Bounty Programs

My methodology for finding Host header injection on bug bounty targets is systematic rather than random. I prioritise three categories: any endpoint that sends emails with links (password reset, email verification, invitation, subscription confirmation), any endpoint that generates or redirects to absolute URLs, and any endpoint with visible caching headers. These three categories cover the majority of exploitable HHI surfaces.

For testing efficiency, I use Burp Suite’s active scanner to test Host header injection automatically across the target’s endpoints, then manually verify and escalate any findings. The scanner catches the obvious cases; manual testing with override headers catches the bypasses. On older PHP and custom-built platforms, I specifically look for the password reset flow first — it’s the most likely exploitable surface and the highest payout potential.

Reporting — Demonstrating the Full Attack Chain

A Host header injection report that demonstrates only the injection — “I changed the Host header and it was reflected” — gets triaged as Low. A report that demonstrates the complete account takeover chain gets triaged as High or Critical. The difference is the impact demonstration. My report structure for password reset poisoning: