CRLF Injection: When a Newline Becomes a Weapon

HTTP response splitting → open redirect

Same trick, different payload:

The server responds with:

The app was never supposed to redirect. The attacker injected the Location header through the URL path.

This is useful because the response itself comes from trusted.com. Phishing filters, link scanners, and email gateways will see the domain as legitimate. Only the redirect destination is malicious.

It's also a great chaining primitive, combine it with SSRF or client-side path traversal and you can bounce a trusted-origin redirect to anywhere.

HTTP response splitting → full response forging

The Acunetix classic, and still worth understanding:

Read that carefully. The attacker is injecting:

1. Content-Length: 0 to terminate the original response body
2. A double CRLF to end the headers
3. A complete second HTTP response — status line, headers, body, all inside the original response

Depending on the proxy, the browser, and how they handle the injected bytes, the second response gets parsed as a new message. Sometimes the browser renders it. Sometimes a cache stores it under the attacker's URL. Sometimes a proxy desyncs and serves it to the next user.

This is where CRLF injection stops being "reflected XSS with extra steps" and starts being infrastructure-level.

HTTP request smuggling via CRLF

If the injection point is itself an HTTP client (an SSRF target, a webhook handler, a soap client), you can inject a second request rather than a second response.

The classic example is PHP's SoapClient. The user_agent parameter is used verbatim in the HTTP request it constructs:

The user_agent contains CRLFs, so the request the SoapClient sends to 127.0.0.1:9090 is actually:

1. The legitimate first request (truncated by the injected double CRLF)
2. A fully attacker-crafted second request

If there's a service listening on that port (a proxy, an admin API, anything), it processes both requests. The first one looks innocuous. The second one does whatever the attacker wants.

PortSwigger's research on "response queue poisoning" takes this further: by injecting Connection: keepalive plus a second request, you can poison the response queue that the next user's request will read from. That's not just XSS — that's a shared-infrastructure bug where every user after you gets your response.

Memcache injection

Here's a bug class that's genuinely underrated.

Memcache speaks a plaintext protocol. Commands are separated by CRLF. If an app builds a memcache command from user input without sanitizing, the attacker can inject additional commands.

The Zimbra case (Sonarsource writeup) is the canonical example. Cache keys were used to store the IP:port a user should connect to. Attackers injected memcache commands via CRLF to poison the cache, redirecting victims to attacker-controlled servers that harvested usernames and passwords.

There was a second primitive in the same bug: response desynchronization. By injecting into one request, the attacker could make memcache return responses intended for a different user — leaking the attacker's IP : port to users whose email the attacker didn't even know.

That's the level of bug you get when a text protocol meets unsanitized input. If the target uses memcache, Redis, or any other line-oriented protocol and reflects user input into commands, this is worth testing.

Session file poisoning: the cPanel chain

This is the one I want to spend time on, because it's the modern example of how CRLF turns into an auth bypass.

In 2026, cPanel and WHM had a pre-auth session file poisoning bug (CVE-2026–41940). The details:

1. cPanel persists session state as line-oriented key=value records in a file before authentication completes.
2. A request-derived value — the password field, in one variant, reached the session writer with \r and \n intact.
3. Because the session file is line-oriented, the injected CRLFs created new session keys.

An attacker who could inject:

would produce a session file with:

The session was never authenticated. But the file now says it was.

The optional-secret downgrade

There's a subtle detail that made this much worse.

cPanel used structured session cookies where one component selected the storage file and another component enabled encryption. Specifically, session_id, and session_id resolved to the same raw file, but omitting disabled password encoding.

So an attacker could:

1. Create a legitimate pre-auth session.
2. Grab the session ID.
3. Reuse it without the secret suffix.
4. Send a payload with CRLF in the password field.
5. The CRLFs reach the line-oriented file unencoded.

Without the optional secret, the whole session file was written raw. The CRLF sanitizer wasn't in the writer — it was in some callers, and the caller the attacker used wasn't one of them.

The cache-parser differential

The bug got deeper.

cPanel maintained two session stores: a canonical text file and a preferred JSON cache. The text parser treats \r and \n as record boundaries. The JSON serializer preserves them inside a single string.

A successful write to the raw store didn't immediately break authentication, because the app reads from the JSON cache first. But the app also had maintenance path - error handlers, repair routines, counter updates,that did this:

1. Open the raw store (bypassing the cache).
2. Parse the injected lines as separate map entries
3. Modify some unrelated field.
4. Rewrite both the raw store and the JSON cache.

At step 2, the forged keys get promoted into the map. At step 4, the promoted keys get written into the JSON cache. Now the app reads the forged keys during normal session loads.

The trigger in the cPanel chain was simple: request a protected route without the URI security-token prefix. That hits a token-denied handler, which increments a counter, which reads the raw file, which promotes the forged keys, which regenerates the cache.

The authorization path then checked successful_internal_auth_with_timestamp, a forged truthy value, and returned success without consulting ****/etc/shadow. Combined with the forged user=root, hasroot=1 , and tfa_verified=1, the pre-auth session became a root-authenticated admin session.

All from a newline in a password field.

The lesson

Session file poisoning is one of those bugs that only exists because of an architectural pattern: persist session state as line-oriented text before authentication finishes. If any request-derived value reaches that file with CRLF intact, the attacker can create new session keys.

The fix isn't a sanitizer in every caller. It's a sanitizer in the writer, the single choke point where session values get serialized. And it's removing the "optional secret" pattern that let one component silently downgrade to unencoded writes.

NetMRI: a different flavor of the same bug

The same primitive showed up in a different product in a different way.

Infoblox NetMRI exposed SetRawCookie.tdf and SetCookie.tdf , endpoints that let authenticated users write a cookie to a session file. The URL-decoded value was stored with CRLF intact.

An attacker with Process Manager access could send:

The decoded value is xyz\r\nUserName=admin. The session file gets a second line. The reader trusts the injected UserName=admin line as the session identity.

Same bug, different sink. The prerequisite is "authenticated user with Process Manager access" instead of "preauth session", but the impact, impersonating any user — is just as bad.

The takeaway: any endpoint that writes to a line-oriented file is a CRLF sink. Cookie writers, config managers, log rotators, session savers. All of them.

Unicode and control-character bypasses

Modern WAFs and rewriters strip literal \r and \n . Some of them forget about the other characters that many back-ends treat as line terminators.

When CRLF is filtered, try:

• %E2%80%A8 - U+2028 LINE SEPARATOR
• %E2%80%A9 - U+2029 PARAGRAPH SEPARATOR
• %C2%85 - U+0085 NEXT LINE

Apache HttpClient had a bug (HTTPCLIENT-1974) where a "sanitized" header value could still introduce a newline via a Unicode character. The sanitizer had been validated against ASCII CRLF only.

Payload:

If the filter normalizes UTF-8 first, turning the Unicode separator into a regular line-feed — the injected header gets accepted. If it doesn't, the backend still treats the character as a line boundary when it parses.

Test the exact client, proxy, and back-end chain. Different components in the same chain may disagree about which characters count as newlines.

WAF evasion via Content-Encoding and Content-Length

One more trick, because it's clever.

If you have full header injection, including control over Content-Length and Content-Encoding, you can confuse the response framing.

Payload fragment:

Content-Encoding: identity means "no encoding applied." Some intermediaries (proxies, CDNs, WAFs) treat this as a signal that the body is safe to pass through unmodified. If they do, and the injected ContentLength matches the attacker's body bytes, the response framing gets reinterpreted, and the attacker's bytes after the header block become the response body.

Exploitability depends heavily on the proxy and browser behavior. Test carefully, on authorized targets only.

The cheatsheet

Six patterns worth memorizing.

1. Basic response splitting:

Check if the response contains the injected Set-Cookie.

2. CRLF + open redirect:

3. CRLF → XSS:

4. Filter bypass via Unicode:

5. URL path injection:

6. Header injection to smuggling:

Recent CVEs worth knowing

These are valuable because they show CRLF injection is not a legacy bug, it's in modern libraries.

• RestSharp (CVE-2024–45302, 2024) - the AddHeader() helper didn't sanitize CR/LF. Any backend service using RestSharp as an HTTP client could be coerced into SSRF or request smuggling via an attacker-controlled header value. Payload: client.AddHeader("X-Foo", "bar%0d%0aHost:evil").
• Refit (CVE-2024–51501, 2024) - header attributes on interface methods were copied verbatim. Same primitive, different library. Server-side worker jobs using Refit were exploitable.
• Apache APISIX Dashboard (GHSA-4h3j-f5x9-r6x3, 2023) - user-supplied redirect parameter echoed into a Location: header without encoding. Open redirect + cache poisoning.

The pattern: any internal component that performs HTTP requests or sets response headers is a CRLF sink. Not just the web server edge. Not just the user-facing endpoint. Every library, every client, every wrapper.

This is why you should include library versions in your recon and search for their CRLF advisories.

The checklist

Not exhaustive, but this is the order I go in:

1. Find every parameter that ends up in a response header, redirect, or log line.
2. Test %0d%0a - does it create a new header or break the response?
3. Test %0d%0a%0d%0a - does the body start where you injected?
4. Test %0d%0aLocation:%20https://attacker.com - does the response redirect?
5. Test %0d%0aSet-Cookie:admin=true - does the cookie get set?
6. Test the URL path directly, some servers mishandle CRLF in the path component.
7. Test Unicode separators if %0d%0a is filtered: %E2%80%A8 , %E2%80%A9 , %C2%85.
8. Test Content-Length and Content-Encoding injection for framing attacks.
9. If the app talks to memcache, Redis, or another line-protocol service, test injection into that protocol.
10. If the app writes sessions or config to line-oriented files, test injection into the writer.
11. Check whether any request goes to an internal HTTP client (SoapClient, RestSharp, Refit, Guzzle, etc.), that's a smuggling sink.
12. Look for "optional" cookie components that disable sanitization or encoding.

The fix

For developers, the correct pattern is:

• Never put user input into response headers. Full stop.
• If you must, use the language's built-in header-setting function, in modern PHP, Go, Java, and Node, these reject CR/LF automatically.
• Don't write session data as line-oriented text if any field is user-controlled. Use a serialized format (JSON, msgpack, protobuf) that treats CRLF as data.
• If you must use line-oriented storage, sanitize in the writer, not in every caller. One choke point is auditable; scattered sanitizers are not.
• Don't do "optional" secret/encoding flags. Every code path must enforce the same protections.
• Update your HTTP client libraries. RestSharp, Refit, Apache HttpClient, and others have all had CRLF bugs. Check versions during recon.

The thing to remember

CRLF injection is a bug class that only exists because HTTP is a text protocol built on line terminators.

Every layer that parses text, response headers, log files, session files, memcache commands, HTTP client requests, has the same weakness: a newline in user input is a new instruction.

The shallow bugs get you XSS and open redirects. The deep bugs get you request smuggling, session poisoning, and authentication bypass.

And the pattern keeps reappearing in new places, libraries in 2024, session files in 2026. It's not going away. Every time someone builds a new line-oriented format, they forget that CRLF is data, not decoration.

When you're testing, don't just look at the URL. Look at what happens to the input after it leaves the URL, where it gets stored, what it gets concatenated into, what parser eventually reads it.

That's where the bug lives.

That's Part-11. Read the whole series in order: Web Pentesting: A Complete Guide.