CVE-2026-93711 in Dancer2
Summary
by MITRE • 09/22/2026
Dancer2 versions before 2.2.0 for Perl do not strip CR and LF from response header names in headers_to_array.
The routine removes CR and LF from each header value but not from the name. A name carrying them therefore reaches the PSGI server intact. A server that does not validate keys writes it to the wire, so the bytes after the CRLF arrive as their own header line.
The application has to derive the header name from request data, not just the value.
An attacker who controls that data adds their own headers and splits the response.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
Dancer2 versions prior to 2.2.0 contain a critical input validation flaw within the headers_to_array routine that allows for HTTP Response Splitting attacks when header names are derived from untrusted user-supplied data. The vulnerability stems from an asymmetry in how the framework processes HTTP headers, specifically stripping carriage return and line feed characters only from header values while leaving header names untouched. This oversight creates a pathway for attackers to inject malicious control sequences into the response stream by manipulating the keys of hash structures that are passed through this routine.
The technical root cause lies in the implementation logic where the framework iterates over headers to sanitize them before passing them to the underlying PSGI server. While the code correctly applies sanitization functions to remove newline characters from the values associated with each header, it fails to apply equivalent filtering to the keys themselves. Consequently, if an application developer constructs a response using data sourced directly from user input for the header names, those raw inputs are transmitted verbatim to the PSGI server without validation. This behavior violates fundamental security principles regarding the handling of metadata in HTTP protocols.
When this flawed routine processes a maliciously crafted header name containing embedded carriage return and line feed sequences, these characters reach the web server intact. Most PSGI-compliant servers do not perform additional strict validation on header keys before writing them to the network socket. As a result, the injected newline characters cause the HTTP response parser to interpret subsequent bytes as new headers rather than part of the original name. This effectively splits the single intended response into multiple distinct responses, allowing an attacker to inject arbitrary content such as JavaScript code or modify cache control directives.
The operational impact of this vulnerability is significant and aligns with CWE-113, Improper Neutralization of CRLF in HTTP Headers, which facilitates HTTP Response Splitting. This class of attacks can lead to various downstream security issues including cross-site scripting if the injected content includes script tags that are executed by victim browsers due to improper cache poisoning or response manipulation. It also undermines data integrity and confidentiality as attackers may be able to redirect users or inject malicious payloads into cached responses, affecting multiple users who access the compromised resource.
Mitigation strategies must focus on strict input validation at the application layer since framework-level fixes were not applied in versions before 2.2.0. Developers should ensure that any data used for HTTP header names is strictly validated against a whitelist of allowed characters, typically alphanumeric and hyphens, rejecting or encoding any control characters such as CR and LF. It is imperative to avoid using user-supplied input directly as header keys without rigorous sanitization. Upgrading to Dancer2 version 2.2.0 or later resolves this issue by implementing proper stripping of CRLF from both header names and values within the headers_to_array routine, thereby closing the attack vector described in ATT&CK technique T1567 regarding Hostname Spoofing via HTTP Response Splitting mechanisms.