hunt-host-header

> **⚠️ AUTHORIZED USE ONLY**

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> **Mandatory confirmation gate**

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

# 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 for