Cybersecurity glossary

What is CRLF Injection?

Learn what CRLF injection is, how carriage return and line feed sequences split HTTP headers or log lines, what impacts follow, and how to neutralize control characters safely.

Application securityUpdated August 11, 2026
Also known asHTTP response splittingCarriage return line feed injectionNewline injection

Definition

CRLF Injection is a vulnerability in which untrusted input containing carriage return (CR, \r) and/or line feed (LF, \n) characters is written into structured text protocols or logs, allowing attackers to insert new lines, forge headers, split responses, or manipulate downstream parsers.

Why CRLF injection matters

Line breaks are protocol control characters, not ordinary text. HTTP, SMTP, and many log formats use CR and LF to mark structure. When applications copy request data into those formats, CRLF Injection lets attackers redraw the boundaries.

A single %0d%0aSet-Cookie: sequence can fixate sessions or poison caches. The same idea in logs can fabricate audit trails or break SIEM parsing—quietly undermining incident response.

How CRLF injection works

1

Find a line-oriented sink

Redirects, Content-Disposition, custom headers, email fields, or structured logs echo user input.

2

Inject CR/LF sequences

Payloads introduce %0d%0a / \r\n to terminate the current field early.

3

Parser accepts forged structure

New headers, log lines, or response sections appear as if the server authored them.

4

Downstream systems are abused

Browsers, caches, mail agents, or SIEMs act on the attacker-shaped message.

Where CRLF shows up

HTTP headers

Response splitting, Set-Cookie injection, and security header overwrites.

Logging pipelines

Forged events, broken multiline parsing, and alert evasion.

Email protocols

Extra recipients or headers via newline injection in mail fields.

Exports and reports

Line-based formats where injected breaks reshape records.

Prevention that works

ControlNotes
Reject control charactersBlock CR, LF, and other C0 controls before writing headers
Use safe header APIsFramework setters that encode or refuse illegal header values
Encode log fieldsJSON logs or escaped fields keep events as single records
Allowlist dynamic valuesRedirect targets and filenames should match strict patterns
Normalize then validateDecode URL encoding and Unicode before CR/LF checks
Test proxies separatelyIntermediaries may interpret splits differently than origin apps
  • Identify every sink that writes request data into headers, mail fields, or line logs.
  • Reject or strip CR/LF after URL decoding and Unicode normalization.
  • Prefer structured logging (JSON) over raw concatenated log lines.
  • Add tests with %0d%0a payloads on redirects, downloads, and custom headers.
  • Verify CDN/proxy behavior for response-splitting style inputs.
  • Review email-sending code for header concatenation from user input.
  • Ensure security headers are set by the framework, not string templates.
  • Treat exploitable HTTP response splitting as high severity.

The practical takeaway

CRLF injection exploits newline characters that protocols treat as structure. Keep control characters out of headers and line-oriented outputs, and validate after decoding.

If user input can become a header value, assume attackers will try to end that line early.

Related security terms

Frequently asked questions

What is CRLF injection in simple terms?

CR and LF are the characters that mean 'new line' in many protocols. If an app writes user input into headers or logs without removing those characters, an attacker can start a new line and add content the developer never intended.

Is CRLF injection the same as HTTP header injection?

HTTP header injection is a common instance of CRLF injection. CRLF issues also appear in logs, CSV-like exports, and other line-oriented formats.

What can attackers achieve?

Impacts include response splitting, session fixation via Set-Cookie, cache poisoning, cross-site scripting through split bodies, security-header overwrites, and forged log entries that hide or invent events.

How do payloads usually look?

Encoded sequences such as %0d%0a or raw \r\n embedded in redirects, filenames, or query values that later become header fields.

Do modern frameworks still allow this?

Many frameworks reject CR/LF in header APIs, but raw response writers, older middleware, reverse proxies, and custom logging can still be vulnerable.

How do you prevent CRLF injection?

Strip or reject CR/LF from any data written into headers or line-based outputs, use framework header APIs, and encode log fields so newlines cannot break event boundaries.

Is filtering only \r\n enough?

Prefer rejecting all control characters in these contexts. Some stacks normalize unusual Unicode line separators; validate after decoding and normalization.

References

Explore authoritative guidance and frameworks related to crlf injection.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary