This article is a comprehensive technical guide to finding, testing, and escalating CRLF injection vulnerabilities in bug bounty programs. It covers how attackers inject carriage return and line feed characters (%0d%0a) into HTTP response headers to add arbitrary headers, split responses, or inject malicious content. The article demonstrates that CRLF injection payouts vary dramatically based on impact escalation—from $100 for basic header injection to $10,000+ for cached XSS—making systematic escalation critical to maximizing bug bounty rewards.
- HTTP header structure enables CRLF attacksHTTP/1.1 separates headers with CRLF (rn) and terminates the header section with double CRLF (rnrn). When applications concatenate unsanitized user input directly into header values—particularly in Location, Set-Cookie, or custom headers—an attacker can inject %0d%0a characters to create new headers or, with double CRLF, inject an entirely new response body. The vulnerability stems from servers treating every occurrence of this two-character sequence as a structural boundary.
- Redirect parameters are primary injection targetsCommon vulnerable parameters include next=, return=, redirect=, url=, r=, and goto= on login endpoints, logout flows, OAuth callbacks, and post-action redirects. The article instructs testers to systematically map all redirect endpoints using Burp Suite's HTTP history filtered by 302 responses, then test each parameter with a basic CRLF payload like %0d%0aX-CRLF-Test:injected. Because these endpoints are designed to handle redirects, their parameter values naturally flow into response headers, creating direct injection points.
- Set-Cookie injection demonstrates session fixationBy injecting a Set-Cookie header via CRLF, an attacker forces a victim's browser to store a known session value before login. The attack chain works by: attacker crafts a malicious link with CRLF payload, victim clicks it and receives the injected Set-Cookie header, victim logs in causing the app to associate the attacker's session value with the victim's authenticated account, and attacker uses that same session value to access the victim's account. The article notes this is the most reliably demonstrable high-impact escalation in 2026, more reliable than response splitting which varies by br
- Response splitting injects arbitrary HTML and JavaScriptBy using a double CRLF sequence followed by Content-Length: 0 and another full HTTP response structure, an attacker can terminate the original response headers and inject a completely new response with arbitrary HTML and JavaScript. The payload structure includes injected response headers, another double CRLF to end those headers, and then malicious content like that executes on the target domain. The article warns this can cause cache poisoning affecting all users if the injected response is cached.
- WAF evasion requires testing multiple encodingsStandard %0d%0a encoding is often blocked, but alternative encodings bypass filters: double URL-encoded %250d%250a (decoded twice by some parsers), LF-only %0a (vulnerable on older Apache), Unicode %u000d%u000a, and CRLF plus tab %0d%0a%09. The article emphasizes that if basic CRLF is blocked, most testers stop testing and mark endpoints as secure; however, systematic bypass testing of at least double-encoding, LF-only, and Unicode variants finds CRLF injections others miss. Testing different payload positions (beginning of value, after a slash, with different context) also helps.
- Payout scales directly with demonstrated impactThe article establishes a severity escalation ladder: basic header injection ($50-200), Set-Cookie injection ($300-1,500), XSS via response splitting ($1,000-5,000), and cache poisoning XSS ($3,000-15,000+). The same injection point tested at only the lowest level might yield $100, but escalated to Set-Cookie fixation yields $1,000, and further escalated to cached XSS yields $5,000-10,000. This creates a financial incentive to invest time in escalation testing rather than filing reports at the lowest impact level discovered.
- Manual testing with Burp Repeater confirms exploitabilityThe article prescribes capturing both request and response panes in Burp Suite Repeater as evidence: the request showing the payload with %0d%0a or bypass encoding, and the response showing the injected header appearing in the response headers section. Additionally, for Set-Cookie injection, screenshotting the injected cookie in the browser's Application tab (Cookies storage) provides more compelling evidence than a Burp response alone. This manual workflow builds testing discipline and ensures bypass encodings are tested systematically.
- Bug reports must demonstrate maximum impact before submissionThe article provides a report structure requiring: title including endpoint and highest-impact finding, severity level based on demonstrated impact (not theoretical), description in non-technical terms, exact numbered reproduction steps that require no interpretation, evidence screenshots showing payload and injected content, business impact explanation written for non-security managers, and remediation guidance. The article stresses self-assessment: if reproduction requires guesswork, the steps aren't precise enough; if impact uses technical jargon, rewrite it for non-security audiences. Repo
Bottom line: CRLF injection remains a high-payout vulnerability because most testers file reports at the basic header-injection level without attempting escalation to Set-Cookie fixation or response splitting XSS—yet the same injection point escalated to higher impact can yield 10-100x higher payouts. Success in CRLF bug bounty hunting depends on systematic bypass testing when standard %0d%0a encoding is blocked, disciplined escalation from basic injection through Set-Cookie to response splitting, and precis
FREE
Part of the 60-Day Bug Bounty Mastery Course
✅ Before You Start
- Day 23: WebSocket Attacks — complete this first. The tools and concepts from that session are assumed here.
- Burp Suite Community running and configured as browser proxy. Active bug bounty program in scope OR PortSwigger Web Security Academy free account.
🎯 After Day 24
⏱️ 35 min read · 3 exercises · Day 24 of 60
📋 Day 24 — CRLF Injection Bug Bounty
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.
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.
⏱️ 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.
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.
📸 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.
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.
%0a) alongside the full CRLF (%0d%0a). Some servers are vulnerable to LF injection but filter CRLF. This is especially common on older Apache configurations where only the carriage return character triggers security filters.Encoding Bypasses for WAF Evasion
WAFs and input filters often block %0d%0a but miss alternative encodings. My bypass test sequence:
⏱️ 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.
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?
📸 Screenshot the injected Set-Cookie in Burp response headers. Share in #bug-bounty.
🧠 Section Check
?url=https://site.com%0d%0aX-Test:injected and get an HTTP 400 error instead of the redirect. What does this indicate and what should you try?
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.
⏱️ 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.
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]
EVIDENCE:
Screenshot 1: Request with CRLF payload in Burp Repeater
Screenshot 2: Response headers showing injected header
Screenshot 3: [If Set-Cookie: browser cookie storage]
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?
📸 Share your completed report (anonymised PoC details) in #bug-bounty. Tag #Day24
CRLF Injection in Bug Bounty Programs — Program Selection
Not all bug bounty programs treat CRLF injection equally. Understanding program policies before investing testing time helps prioritise where CRLF findings are most likely to be well-received and paid appropriately.
Programs that explicitly list “HTTP header injection” or “HTTP response splitting” as in-scope generally pay more fairly for CRLF than programs that don’t mention it. Programs running on custom frameworks or older PHP/Java applications are more likely to be vulnerable than those running on modern frameworks with built-in header sanitisation. My targeting strategy: check the program’s past Hacktivity disclosures for CRLF reports — if none exist, the program either sanitises headers well or no one has found CRLF yet. Both cases are interesting.
The authentication and redirect flow endpoints are the highest-value targets. Every login flow, logout redirect, OAuth callback, and post-action redirect in the application is worth testing. These endpoints handle redirects by design — the parameter the application reads for redirect destination is your primary injection target. Systematic mapping of all redirect endpoints before testing ensures comprehensive coverage.
📋 CRLF Injection Payloads — Day 24
🏆 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
?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?
How is CRLF different from HTTP response splitting?
What severity is CRLF injection in bug bounty?
What encodings should I test for CRLF?
Which tools detect CRLF automatically?
Where does CRLF injection most commonly occur?
Day 23: WebSocket Bug Bounty 2026
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.

