CRLF Injection / HTTP Header Injection

Reports cluster around:

• classic HTTP response splitting via newline in user input that ends up in a Set-Cookie / Location header
• SMTP command injection via newlines in app-config fields (Grafana SMTP password, Nextcloud Calendar appointment description) leading to RCE through email rendering misuse
• LDAP password field with embedded newlines smuggling SMTP / Redis commands
• Library bugs (Ruby net/http set_content_type, Cloudflare Transform Rules concat() decoding hex escapes) where newline in a value reaches the final HTTP request unescaped.

• Endpoints reflecting parameters into Location / Set-Cookie / custom headers
• App-config UIs (SMTP host/port/user/pass, LDAP DN)
• Email-rendering / SMTP-using features
• Reverse proxy / CDN rule engines

• Inject %0d%0a into URL parameter that is reflected into Location / Set-Cookie
• Inject newline into SMTP password / from / to fields used by app-config
• Inject newline into LDAP password field used as DN fragment
• Use hex escapes \x0a\x0d to bypass naive newline filters

• %0d%0aSet-Cookie:+evil=1
• %0d%0aLocation:+https://evil.com
• x\r\nHeader: injected
• password\r\nMAIL FROM:<attacker@evil>
• \x0a\x0dHeader: smuggled (Cloudflare concat)

Inject %0d%0aX-Test-Probe:hit into URL parameters that end up in Location / Set-Cookie / X-* response headers; flag when X-Test-Probe header appears in the response.

When authenticated config UI has SMTP/LDAP credential fields, mark as high-risk surface and add to authenticated-scan checklist.

Compose with Nuclei for known CRLF/HRS-via-config CVEs.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• Many reflections are encoded - only flag when the probe header actually appears in the response.
• SMTP-via-config requires authenticated state.

Manual Testing Methodology

Here is a systematic approach to identifying CRLF Injection / HTTP Header Injection vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For CRLF Injection / HTTP Header Injection specifically, submit %0d%0a (and raw \r\n where the transport allows it) followed by a new header name/value or a fake log line into every parameter that ends up reflected in a response header, Set-Cookie value, redirect target, or logged field.

Compare the response against your baseline, looking specifically for an extra, attacker-defined header appearing in the raw HTTP response, a split response body, or a forged entry appearing in application logs.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For CRLF Injection / HTTP Header Injection, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

CRLF and HTTP header injection let an attacker insert carriage-return/line-feed sequences into a value that ends up in a raw HTTP header or a log line, splitting what should be a single header into multiple, or a single log entry into several. In a header context, this can inject entirely new response headers, split the response into two, or plant content the application never intended to serve — including a second, attacker-controlled response body.

The practical exploits built on this primitive include HTTP response splitting (poisoning what an intermediate cache stores and serves to other users), session fixation via an injected Set-Cookie header, and open-redirect-adjacent phishing via an injected Location header — the specific impact depends on which header ends up attacker-controlled.

In logs specifically, CRLF injection enables log forging: an attacker can fabricate fake log entries designed to mislead an investigator or hide evidence of the real attack among plausible-looking noise.

Prevention and Secure Coding

Preventing CRLF Injection / HTTP Header Injection takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Reject CR/LF in header and log values outright. Strip or reject \r and \n characters from any user input that will be placed into an HTTP header value or a log line — don't attempt to escape them, reject the input.

Use framework header-setting APIs. Set headers and cookies through the framework's own API (which typically encodes or rejects invalid characters automatically) rather than concatenating raw strings into a header block.

Validate redirect and cookie values against a strict format. Where a value must go into a Location or Set-Cookie header, validate it against an allowlist format before use, not just against CR/LF.

Structured logging. Use a structured (e.g. JSON) logging format rather than freeform string concatenation, which makes log forging via embedded newlines far harder to pull off convincingly.