Home > Website Pentesting

Host Header Injection

Host header injection occurs when a web application relies on the value of the Host header without validating it. Because clients fully control the Host header, attackers can manipulate it to poison URLs, reset flows, password-reset emails, caching layers, routing logic, and internal security controls.
Many frameworks and reverse proxies trust Host automatically, making this one of the most critical but frequently overlooked attack surfaces.

Understanding the Host Header

A normal HTTP request:

GET /reset-password HTTP/1.1
Host: example.com

If attackers modify it:

Host: attacker.com

and the server trusts this value, all generated absolute URLs, routing decisions, and security logic become compromised.

Host header injection is commonly used for high-impact attacks such as password reset poisoning, SSRF, cache poisoning, and routing manipulation in multi-tenant systems.

Why Host Header Injection Happens

It occurs because many backends use the Host header for:

  • building absolute URLs

  • generating password reset links

  • constructing email links

  • verifying tenant/domain ownership

  • internal routing

  • resolving resources

  • security checks

  • log storage and analytics

If the server does not enforce a strict host whitelist, attackers fully control these operations.

Attack Surfaces Affected by Host Header Manipulation

Password Reset URL Poisoning

If application generates reset URLs using the host:

https://example.com/reset?token=abc

Attacker injects:

Host: attacker.com

Victim receives:

https://attacker.com/reset?token=abc

Attacker steals the token → account takeover.

Email Verification Link Poisoning

Verification emails often contain:

Host: example.com

If attacker changes it:

Host: evil.com

User clicks verification link on attacker’s domain.

Cache Poisoning

If reverse proxies or CDNs use Host for cache keys:

Host: example.com

→ legitimate cached page

Attacker sends:

Host: evil.com

Proxy stores a poisoned response.
Now all users receive attacker-controlled content.

SSRF via Host Routing

Some servers forward requests internally based on Host.
If attacker uses:

Host: 127.0.0.1

server may route the request to internal admin panels.

Virtual Host Confusion

Shared hosting environments use Host to differentiate apps:

Host: victim.com

But attacker sets:

Host: other-app.com

leading to cross-tenant leaks.

Bypassing Security Filters

If WAF filters based on hostnames:

  • blocks access to /admin for example.com

  • but attacker uses Host: attacker.com

Backend may process /admin without restriction.

Log Poisoning

Host header may be written to logs:

Host: <script>alert(1)</script>

Used for XSS when logs are viewed in a web UI.

CSRF + Host Injection

If application uses Host as CSRF origin check:

if (Origin.host === Host) allow();

Attacker sets:

Origin: evil.com
Host: evil.com

Weak comparisons allow CSRF to bypass validation.

Practical Host Header Injection Testing

Step 1: Modify Host Header

Original:

Host: example.com

Test variations:

Host: attacker.com
Host: evil.example.com
Host: 127.0.0.1
Host: localhost
Host: internal-service

Observe:

  • routing changes

  • redirect changes

  • absolute URLs

  • API behavior

Step 2: Add Duplicate Host Headers

Some servers use first header, others use last:

Host: example.com
Host: attacker.com

Check which value is used.

Step 3: Use X-Forwarded-Host

Reverse proxies often rewrite hosts using:

X-Forwarded-Host: attacker.com

If backend trusts this header → critical.

Step 4: Inspect Generated Links

Test endpoints that generate URLs:

/reset-password
/verify
/share
/export
/oauth/callback

Inject Host:

Host: evil.com

Check if response body or email now includes malicious hostname.

Step 5: Attempt Cache Poisoning

Send:

Host: evil.com

Check if subsequent users receive poisoned content.

Step 6: SSRF via Host Routing

Try:

Host: 127.0.0.1

If app resolves internal resources → SSRF possible.

Step 7: Log Injection

Inject unexpected characters:

Host: <script>alert(1)</script>
Host: %0d%0aInjected-Header: bad

If logs or downstream components use these values → XSS or response splitting occurs.

Advanced Host Header Attack Payloads

Absolute URL Construction Exploit

If backend builds URLs like:

base_url = "https://" + request.host

Attacker can send:

Host: attacker.com:443/path

Backend produces:

https://attacker.com:443/path/reset?token=abc

Host Override with Tabs/Spaces

Host: example.com    attacker.com

Some parsers take everything after the first space.

Protocol Injection

If backend appends "https://":

Host: attacker.com#/

Final URL becomes:

https://attacker.com#//reset?token=abc

CRLF in Host Header

Host: attacker.com%0d%0aSet-Cookie:session=steal

If interpreted, this leads to header injection.

Exploiting Common Host Header Anti-Patterns

Mistake 1: Using Host to Validate the Domain

if request.host.endsWith("example.com"):
    allow()

Payload:

Host: example.com.attacker.com

Mistake 2: Using Host for CSRF Origin Verification

Developers compare:

if Origin.host == Host:
    allow()

Attacker sets:

Origin: evil.com
Host: evil.com

Mistake 3: Using Host for Absolute URL Construction

https://{Host}/reset

Always exploitable unless Host is validated strictly.

Mistake 4: Accepting X-Forwarded-Host Blindly

Reverse proxies often set:

X-Forwarded-Host

Attackers simply override it.

Realistic Exploit Scenarios

Password Reset Takeover

Attacker makes victim request password reset email.

Victim receives:

https://evil.com/reset?token=abc

Attacker steals token and resets password.

Admin Panel Routing Bypass

Setting:

Host: internal-admin

Backend routes to private admin app.

Cache Poisoning

Proxy caches page under attacker-supplied host.

All users receive poisoned version.

Open Redirect via Host Injection

Response includes:

Location: https://evil.com/dashboard

Attacker controls destination.

Why Host Header Injection Is So Common

It occurs because:

  • developers trust headers by default

  • frameworks auto-bind request.host

  • proxies and load balancers rewrite hosts inconsistently

  • multi-tenant systems rely heavily on Host

  • security checks incorrectly depend on Host

  • email and reset flows use Host to build URLs

Host must NEVER be trusted from client requests.

Impact of Host Header Injection

This vulnerability enables:

  • stealing password reset tokens

  • redirecting users to phishing domains

  • account takeover

  • cache poisoning

  • SSRF by internal routing

  • bypassing security filters

  • injecting malicious headers

  • XSS via log poisoning

  • manipulating OAuth flows

  • login CSRF escalation

Host header injection is a silent but extremely high-impact attack.

Intel Dump

  • Host header is fully attacker-controlled.

  • Used for URL generation, routing, caching, and security checks.

  • Injection enables password reset poisoning, phishing, SSRF, cache poisoning, and admin bypass.

  • Variants include duplicate Host headers, X-Forwarded-Host, encoded values, and subdomain tricks.

  • Impact includes complete account takeover, redirect abuse, or internal service compromise.

HOME LEARN COMMUNITY DASHBOARD