CVE-2026-34715: 
NixOS vulnerability analysis and mitigation

CVE-2026-34715 is an HTTP Response Splitting vulnerability (CWE-113) in the ewe Gleam/Erlang HTTP framework, caused by improper neutralization of CRLF sequences in outgoing response headers. The encode_headers function in src/ewe/internal/encoder.gleam directly interpolates user-controlled header keys and values into raw HTTP bytes without stripping or rejecting \r\n sequences. All versions of ewe prior to 3.0.6 are affected. The advisory was published on March 30, 2026, and assigned CVE-2026-34715 on April 2, 2026. It carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory).

The root cause is CWE-113 (Improper Neutralization of CRLF Sequences in HTTP Headers). The vulnerable encode_headers function in src/ewe/internal/encoder.gleam folds over a list of header key-value pairs and embeds them directly into a BitArray output without any sanitization, meaning if either the key or value contains \r\n (0x0D 0x0A), the resulting byte stream becomes a structurally valid but attacker-controlled HTTP response that terminates the current header prematurely and injects new headers or a second HTTP response body. Notably, ewe does validate CRLF in incoming request headers via validate_field_value() in src/ewe/internal/http1.gleam, but no equivalent protection existed for outgoing response headers prior to the fix. The fix in v3.0.6 introduces a sanitize_header_value/1 Erlang FFI function that strips 0x0D and 0x0A bytes from all header keys and values before encoding (GitHub Advisory, Patch Commit).

An unauthenticated remote attacker can inject arbitrary HTTP response headers and content into responses served by applications built on ewe, enabling HTTP response splitting, HTTP cache poisoning, and cross-site scripting (XSS) attacks against end users. The primary impact is on integrity (CVSS integrity impact: Low), with no direct confidentiality or availability impact at the framework level; however, secondary effects such as session hijacking via injected Set-Cookie headers or XSS payloads delivered through cache poisoning can significantly elevate the practical risk to end users of affected applications (GitHub Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, demonstrating CRLF injection via a crafted GET request with URL-encoded %0d%0a sequences in a query parameter that is reflected into a Location response header. No evidence of in-the-wild exploitation has been reported. The EPSS score is approximately 0.019% (0.000290), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution is available (GitHub Advisory).

1. Identify a vulnerable endpoint: Find an ewe-based application (versions < 3.0.6) that reflects user-supplied input (e.g., a query parameter) directly into an HTTP response header such as Location, Set-Cookie, or Content-Type.
2. Craft the malicious request: Construct a request where the user-controlled parameter contains a URL-encoded CRLF sequence (%0d%0a) followed by an injected header name and value. For example: GET /?next=https://example.com%0d%0aX-Injected:%20true HTTP/1.1
3. Send the request: Deliver the crafted request to the target server using a tool such as netcat:

   printf 'GET /?next=https://example.com%%0d%%0aX-Injected:%%20true HTTP/1.1\r\nHost: localhost\r\n\r\n' | nc -w 2 localhost 8080

4. Observe injected headers: The server responds with the injected header (X-Injected: true) appearing as a legitimate HTTP response header, confirming successful CRLF injection.
5. Escalate the attack: Leverage the injection to perform cache poisoning (by injecting cache-control headers), deliver XSS payloads (by injecting a second HTTP response body with malicious HTML/JavaScript), or hijack sessions (by injecting Set-Cookie headers) (GitHub Advisory).

• Network: HTTP requests containing URL-encoded CRLF sequences (%0d%0a, %0D%0A, \r\n) in query parameters or other user-controlled inputs that are reflected into response headers; unusual or unexpected headers appearing in HTTP responses from the server.
• Logs: Web/application server access logs showing requests with %0d, %0a, %0D%0A, or literal CRLF characters embedded in query string values (e.g., /?next=...%0d%0a...); anomalous response header fields logged by reverse proxies or WAFs.
• Application Behavior: Responses containing unexpected headers (e.g., X-Injected, duplicate Set-Cookie, or injected Content-Type headers) not set by application logic; cache entries containing attacker-controlled content.

Upgrade ewe to version 3.0.6 or later, which introduces the sanitize_header_value/1 Erlang FFI function that strips \r (0x0D) and \n (0x0A) bytes from all response header keys and values before encoding. As a defense-in-depth measure, applications should independently validate and sanitize any user-controlled data before passing it to response headers, explicitly rejecting or stripping CRLF sequences from values used in security-sensitive headers such as Location, Set-Cookie, and Content-Type. Deploying a WAF or reverse proxy configured to block requests containing CRLF sequences in query parameters can provide additional protection for unpatched deployments (ewe v3.0.6 Release, Patch Commit).