CRLF Injection and HTTP Response Splitting Explained
CRLF injection smuggles carriage return and line feed characters (%0d%0a) into headers or logs. In the worst case the server writes attacker-controlled headers or even a second HTTP response — classic response splitting.
Modern stacks and reverse proxies block many cases, but header reflection and log forging still appear in bug bounty.
What to try
Look for user input reflected into:
Location,Set-Cookie,Content-Type, or custom headers- Redirect URLs built from query parameters
- File download names (
Content-Disposition) - Server logs or support tickets that later render oddly
Inject %0d%0aX-Bugflare-Injected: 1 and see whether a new header appears in the raw response.
Impact ladder
- Log injection: forged log lines that confuse monitoring
- Header injection: unexpected response headers
- Cache / XSS chains: splitting that lets an attacker terminate headers and start an HTML body (rarer on modern servers, still worth checking behind odd CDNs)
Safe proof
Show the raw HTTP response with your injected header. Prefer a unique marker over trying to inject scripts into production caches. Stay inside scope and avoid poisoning shared cache keys used by other users.
Report tips
Include the exact encoded payload, the reflected header section, and whether a proxy normalized the input. Suggest stripping CR/LF from any value written into headers and using safe redirect allowlists.
Defensive checklist
- Reject CR/LF in header values.
- Use framework redirect helpers that validate Location.
- Encode log fields; do not treat logs as trusted HTML later.
- Add unit tests that feed
%0d%0ainto redirect and cookie helpers.
CRLF is small characters with header-level power. If input reaches a header writer, test the newline.
Original Bugflare guide informed by OWASP CRLF injection guidance.