CVE-2026-44546: Daphne HTTP Header Injection Vulnerability (4.2.2)

Technical summary

The vulnerability stems from a parser differential between Twisted (which Daphne uses for HTTP parsing) and autobahn (used for WebSocket processing). Twisted does not treat bytes \x0b (vertical tab), \x0c (form feed), \x1c (file separator), \x1d (group separator), \x1e (record separator), or \x85 (NEL character) as header line separators during initial parsing. However, autobahn converts header values to Python strings and invokes splitlines(), which does recognize these characters as line boundaries per Unicode specifications. An attacker can inject these bytes into header values to cause autobahn to split what Daphne considers a single header value into multiple values, effectively injecting synthetic headers into the ASGI scope. The patched version (4.2.2+) rejects requests containing these problematic bytes in any header value with a 400 Bad Request response, preventing the injection vector.

Business impact

Applications relying on header validation or authentication logic could be bypassed if an attacker successfully injects headers that override or supplement expected values. For example, injected headers could influence application routing, bypass rate-limiting headers, or interfere with authentication tokens if the application does not normalize header handling. The practical impact depends heavily on how the downstream application processes headers. However, the low CVSS score and requirement for specific conditions (knowledge of vulnerable header byte sequences and application-specific logic) limits broad exploitability. Organizations should assess whether their applications have header-dependent security controls.

Affected systems

Daphne versions prior to 4.2.2 are affected. Daphne is the reference ASGI application server for Django and is commonly deployed in production environments alongside Django applications. Any organization running Daphne for ASGI workloads—particularly those handling WebSocket connections where this vulnerability is most relevant—should audit their deployment versions. The vulnerability applies regardless of operating system, as it is a parsing logic issue in the Python application itself.

Exploitability

Exploitation requires specific knowledge of the vulnerable byte sequences and understanding of the target application's header processing. An attacker must craft HTTP requests with these bytes embedded in header values and send them over the network. The attack is network-accessible (AV:N) but has high attack complexity (AC:H), meaning successful exploitation depends on application-specific behavior and is not a trivial remote code execution. No user interaction is required. The fact that this vulnerability has not been added to CISA's Known Exploited Vulnerabilities (KEV) catalog suggests limited real-world exploitation at this time, though the vulnerability is valid and patching is prudent.

Remediation

Upgrade Daphne to version 4.2.2 or later. This is a straightforward dependency update for most Django deployments. Organizations should verify the upgrade does not introduce breaking changes in their specific environment. For those unable to patch immediately, consider restricting network access to Daphne endpoints or implementing Web Application Firewall (WAF) rules to reject requests with the problematic byte sequences in headers, though patching remains the definitive remediation.

Patch guidance

Update the daphne package to version 4.2.2 or newer via your package manager (pip, conda, etc.). For pip users: `pip install --upgrade daphne>=4.2.2`. Verify the upgrade by checking `daphne --version` or inspecting your requirements.txt/lockfile. Test the patched version in a staging environment, particularly if your application handles WebSocket connections, to ensure compatibility. Rolling out the patch should carry minimal risk given the nature of the fix (adding validation logic). Coordinate the deployment with your application restart schedule to ensure zero-downtime updates if applicable.

Detection guidance

Monitor HTTP requests arriving at Daphne for the presence of bytes \x0b, \x0c, \x1c, \x1d, \x1e, or \x85 in header values. These are uncommon in legitimate HTTP traffic and their presence is a strong indicator of attempted exploitation. Implement application-level logging to capture suspicious header patterns, or use WAF/IDS rules tuned to detect these byte sequences. After patching, Daphne will return 400 responses for such requests; monitor 400 error spikes as a potential signal of attack attempts. Review application logs for evidence of injected headers affecting security-critical logic.

Why prioritize this

While the CVSS score is low (3.7), the vulnerability represents a meaningful attack surface for applications with header-dependent security controls. Prioritization should reflect organizational risk tolerance and specific application architecture. Organizations with WebSocket-heavy or authentication-sensitive applications should prioritize the patch. The ease of patching (a simple version bump) makes this a good candidate for rapid deployment in standard update cycles. The lack of KEV designation suggests this is not an active exploitation vector at scale, but proactive patching is still warranted.

Risk score, explained

The CVSS 3.1 score of 3.7 (LOW) reflects: network accessibility (AV:N) balanced by high attack complexity (AC:H), requiring both knowledge of the injection technique and favorable application-side conditions; no privilege requirement (PR:N); no user interaction (UI:N); unchanged scope (S:U); and only potential for low confidentiality impact (C:L) with no integrity or availability impact. The attack surface is narrow—limited to applications that process injected headers in security-sensitive ways—and successful exploitation is not guaranteed across all deployments. The score appropriately downweights the risk given these constraints.

Frequently asked questions