CVE-2026-38967: CrowCpp Crow Header Injection Vulnerability

CVE-2026-38967 Overview

CVE-2026-38967 is an HTTP response header injection vulnerability affecting CrowCpp Crow through version 1.3.1. The framework fails to validate response header values before writing them to HTTP responses. Attackers can inject Carriage Return Line Feed (CRLF) sequences into header values to manipulate the response stream. This weakness maps to CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers.

Crow is a C++ microframework used to build HTTP and WebSocket services. Applications that pass user-controlled data into response headers are exposed to header splitting, cache poisoning, and cross-site scripting through injected content.

Critical Impact

Unauthenticated remote attackers can inject arbitrary HTTP headers and response bodies through unvalidated header values, enabling cache poisoning, session fixation, and cross-site scripting against downstream clients.

Affected Products

• CrowCpp Crow versions up to and including 1.3.1
• Applications using Crow HTTP response APIs with user-controlled header values
• Downstream services and proxies fronting vulnerable Crow applications

Discovery Timeline

• 2026-06-02 - CVE-2026-38967 published to the National Vulnerability Database (NVD)
• 2026-06-03 - NVD record last modified

Technical Details for CVE-2026-38967

Vulnerability Analysis

The vulnerability stems from missing neutralization of CRLF sequences in HTTP response header values. Crow accepts arbitrary strings passed to header-setting APIs and serializes them directly into the response stream. When attacker-controlled input reaches a header value, embedded \r\n byte sequences terminate the current header and start a new one. This allows injection of additional headers or a complete second HTTP response.

The attack requires no authentication, no user interaction, and can be triggered over the network against any endpoint that reflects request data into response headers. Common patterns include redirect endpoints copying a Location value from a query parameter, custom headers echoing user-agent or referer values, or cookie-setting routes that mirror input into Set-Cookie.

Downstream impact depends on the deployment. Reverse proxies and caches that trust upstream responses may store poisoned content. Browsers receiving a split response can be coerced into executing injected script through a forged Content-Type: text/html header followed by an attacker-supplied body.

Root Cause

The Crow response serialization path does not reject or escape CR (0x0D) and LF (0x0A) octets when writing header values. RFC 9110 requires servers to reject or sanitize these bytes in field values. The fix discussed in the GitHub Pull Request adds validation that rejects control characters before headers are emitted.

Attack Vector

The attack vector is network-based against any HTTP endpoint that propagates untrusted input into a response header. An attacker submits a request containing URL-encoded %0d%0a sequences in a parameter that the application stores in a response header. The decoded bytes split the response, letting the attacker append arbitrary headers, set cookies, or inject a forged response body. See the GitHub Issue Discussion for the original report.

No verified public proof-of-concept code is associated with this CVE. The vulnerability mechanism is described in prose above and in the upstream issue tracker.

Detection Methods for CVE-2026-38967

Indicators of Compromise

• HTTP request logs containing URL-encoded CRLF sequences (%0d%0a, %0D%0A, or raw \r\n) in query parameters, path segments, or header values
• Response logs showing duplicate Content-Length, Content-Type, or Set-Cookie headers from the same request
• Cache entries containing unexpected Set-Cookie headers tied to user-controllable input
• Outbound responses with header values longer than expected baselines for the route

Detection Strategies

• Deploy a web application firewall rule that blocks raw and encoded CR/LF bytes in request parameters destined for Crow endpoints
• Add server-side logging of every header value written through Crow response builders and alert on control characters
• Run authenticated dynamic application security testing (DAST) scans targeting redirect, cookie, and header-reflection routes
• Compare response header counts and sizes against per-route baselines to surface anomalies

Monitoring Recommendations

• Forward HTTP access logs to a centralized analytics platform and alert on %0d%0a patterns in request fields
• Monitor reverse proxy and CDN logs for cache key collisions and unexpected Vary header changes
• Track Crow application versions across the fleet using software bill of materials (SBOM) tooling
• Review error logs for malformed response warnings emitted by upstream load balancers

How to Mitigate CVE-2026-38967

Immediate Actions Required

• Inventory all services built on CrowCpp Crow and identify versions at or below 1.3.1
• Apply input validation at the application layer to strip CR and LF bytes from any value passed to res.add_header, res.set_header, or cookie APIs
• Place a hardened reverse proxy in front of Crow services to drop responses containing malformed headers
• Audit application source code for routes that copy request data directly into response headers

Patch Information

A fix is tracked in the CrowCpp/Crow Pull Request #1167, which adds validation of response header values. Rebuild and redeploy Crow applications against the patched commit or a release later than 1.3.1 once available. Coordinate the rollout with downstream proxy and cache operators to invalidate any poisoned entries.

Workarounds

• Wrap all header-setting calls in a helper that rejects strings containing \r or \n before invoking Crow APIs
• Encode or hash any user-supplied value before placing it in a response header
• Disable routes that reflect request input into Location, Set-Cookie, or custom headers until the patch is deployed
• Configure upstream proxies such as nginx or Envoy to drop responses with duplicate Content-Length or embedded CRLF in header values

# Example nginx configuration to reject malformed upstream responses
proxy_pass_header Server;
proxy_hide_header X-Powered-By;
proxy_intercept_errors on;

# Block requests containing encoded CRLF before they reach Crow
if ($args ~* "%0[dD]%0[aA]") {
    return 400;
}
if ($request_uri ~* "\r|\n") {
    return 400;
}