CVE-2026-44546 in daphne
Summary
by MITRE • 06/03/2026
daphne before 4.2.2 reconstructs a raw HTTP request from Twisted's parsed headers and feeds it to autobahn for WebSocket handshake processing. Twisted does not treat \x0b, \x0c, \x1c, \x1d, \x1e, or \x85 as header line separators, but autobahn decodes header values to str and calls splitlines(). An attacker can exploit this parser differential to inject additional headers into the ASGI scope passed to the application. daphne now rejects requests with these bytes in any header value with a 400 response.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 06/03/2026
The vulnerability in daphne versions prior to 4.2.2 represents a critical parser differential attack that exploits inconsistencies between Twisted's HTTP header parsing and Autobahn's WebSocket handshake processing. This flaw arises from the fundamental difference in how these two components handle certain control characters within HTTP header values, creating a potential avenue for header injection attacks that could compromise application security. The vulnerability specifically targets the handling of characters \x0b, \x0c, \x1c, \x1d, \x1e, and \x85 which Twisted treats as valid header content but Autobahn interprets differently during the WebSocket handshake process. When daphne reconstructs raw HTTP requests from Twisted's parsed headers for Autobahn processing, these control characters trigger a splitlines() operation that can inadvertently split header values and inject additional headers into the ASGI scope passed to the application. This parser differential creates a scenario where an attacker can manipulate HTTP header values containing these specific control characters to inject malicious headers that will be processed by the application. The impact of this vulnerability extends beyond simple header injection, as it can potentially allow attackers to manipulate application behavior through crafted HTTP requests that appear legitimate to Twisted's parser but are interpreted differently by Autobahn's WebSocket processing layer. The security implications are significant because the injected headers could contain malicious data that influences application logic or bypass security controls, particularly in environments where WebSocket connections are used for application communication.
The technical exploitation of this vulnerability demonstrates a classic case of parser inconsistency that falls under CWE-1295, which specifically addresses issues related to inconsistent parsing of input data between different components in a system. The flaw operates at the intersection of HTTP protocol handling and WebSocket protocol implementation, where Twisted's HTTP parser and Autobahn's WebSocket handshake processor have different interpretations of the same input data. When these components process the same HTTP request, the differences in their handling of control characters create an attack surface where an attacker can craft header values containing these specific control characters to manipulate the final ASGI scope. The splitlines() function call in Autobahn's processing path becomes the critical point where the parser differential manifests, as it treats these control characters as line separators even though Twisted's parser considers them legitimate header content. This differential creates a situation where header values that should remain intact are split into multiple lines, effectively allowing header injection attacks to succeed. The vulnerability is particularly concerning because it affects the core processing pipeline of WebSocket connections in daphne, meaning that any application using daphne with WebSocket support could be vulnerable to this attack vector. The attack requires minimal sophistication as it only requires including one of the specified control characters in a header value, making it a practical threat that could be exploited in automated attacks.
The operational impact of this vulnerability extends to any application using daphne versions prior to 4.2.2 that handles HTTP requests with WebSocket connections, potentially allowing attackers to manipulate application behavior through header injection attacks. The fix implemented in daphne 4.2.2 addresses this by rejecting requests containing these specific control characters with a 400 response, effectively preventing the attack vector at the point of request processing. This mitigation strategy aligns with defensive programming principles and follows the principle of least privilege by rejecting potentially malicious input rather than attempting to process it. The solution prevents the parser differential from being exploited by ensuring that requests containing these control characters are rejected before they can be processed by either Twisted or Autobahn components. This approach is consistent with the ATT&CK framework's approach to mitigating input validation vulnerabilities, where the focus is on preventing malicious input from reaching vulnerable processing components. The fix also demonstrates proper security engineering practices by addressing the root cause rather than attempting to work around the inconsistency between components. Organizations using daphne should prioritize updating to version 4.2.2 or later to prevent exploitation of this vulnerability, as the attack requires no specialized knowledge beyond understanding how to include specific control characters in HTTP headers. The vulnerability affects the broader ecosystem of applications using daphne for WebSocket processing, particularly those in environments where HTTP header manipulation could be used to bypass security controls or influence application behavior. The fix implemented represents a robust security measure that prevents the attack vector while maintaining compatibility with legitimate HTTP requests that do not contain these problematic control characters in header values.