CRLF injection

CRLF are the carriage-return and line-feed characters (\r\n, in URL %0d%0a) that separate headers and lines in text protocols like HTTP and SMTP. If an app reflects user input into a response header, an email or a log without filtering those characters, the attacker injects new lines and with them fake headers, body or entries.

Threat model

HTTP response splitting: inject headers (Set-Cookie for session fixation, Location to redirect) or a second response body.
XSS via body injection in the response.
Web cache poisoning (poison the cached response).
Email header injection: in contact forms, inject Bcc:/To: to send spam or steal.
Log injection/forging: falsify or break log entries (hide tracks, inject misleading data, or even payloads toward systems that process the logs).

Anatomy

It enters where user input ends up in a header or a line of a text protocol: parameters reflected in Location (parameter-based redirects), Set-Cookie, custom headers, email headers, or log files. The key is that %0d%0a is not filtered before writing the header/line.

Red Team

# Header/cookie injection in a parameter-based redirect
/redirect?url=https://x%0d%0aSet-Cookie:%20sid=attacker%3b%20HttpOnly

# Response splitting -> inject body / XSS (double CRLF closes headers)
?q=foo%0d%0aContent-Length:%200%0d%0a%0d%0a<html><svg onload=alert(1)>

# Forced redirect
?lang=en%0d%0aLocation:%20https://evil.tld

# Email header injection (contact form)
name=joe%0d%0aBcc:%20victim@tld.com

# Log forging (falsify a log line)
User-Agent: normal%0d%0a2026-01-01 00:00:00 [INFO] user admin authenticated from 10.0.0.1

Also try encoding variants: %0d%0a, %0D%0A, %E5%98%8A%E5%98%8D (unicode some stacks normalize to CRLF), and only %0a/%0d.

Tooling

Burp Suite (inject %0d%0a in parameters/headers), fuzzing with PayloadsAllTheThings CRLF lists.

Blue Team

Detection

Input with %0d%0a/\r\n reflected in headers; duplicate or unexpected headers in responses; Set-Cookie/Location with parameter-controlled values; log lines with broken structure.

Telemetry and sources

WAF with header inspection, server/app logs, and log integrity validation.

Hardening

Strip/escape CR and LF from any input going to a header, an email or a log.
Don’t put user input in headers; use framework APIs that already reject CRLF in headers (most modern runtimes do).
For email, use libraries that separate headers from body and sanitize fields.
Validate/normalize and encode before logging (avoid log injection).

Response

Fix the header/email/log construction, purge poisoned caches, and invalidate injected cookies (fixation).

CVEs and real-world cases

HTTP response splitting / CRLF affected numerous proxies, frameworks and applications; today many runtimes block CRLF in headers, but it still appears in:
- Code that builds headers by hand (redirects, parameter-based cookies).
- Email forms without sanitization (email header injection).
- Logging systems (log forging), sometimes as a stepping stone to other attacks.

CVEs/incidents in NVD (https://nvd.nist.gov/vuln/search) and GitHub Advisories (https://github.com/advisories).

Testing checklist

%0d%0a injection in parameters going to Location/Set-Cookie.
Response splitting (extra header / body / XSS).
Email header injection in contact forms (Bcc:).
Log injection if input ends in logs.
CRLF encoding variants tested.