CVE-2026-93711: Dancer2 versions before 2.2.0 for Perl do not strip CR and LF from response header names in headers_to_array
Dancer2 versions before 2.2.0 for Perl do not strip CR and LF from response header names in headerstoarray.
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Dancer2to a version that resolves this vulnerability.Fixed in 2.2.0
Event History
Frequently Asked Questions
Which deployments are realistically exposed to response splitting?
Deployments using Dancer2 before 2.2.0 are exposed only when application-controlled request data can influence a response header name and the PSGI server does not validate header keys before writing the response.
What must an attacker control to exploit this issue?
The attacker must be able to cause CR and LF characters to appear in a response header name. Controlling only a header value is not sufficient, because the routine already removes CR and LF from header values.
Are applications that use only fixed response header names affected?
The described attack requires the application to derive a header name from request data. Applications that use fixed, non-request-derived header names do not meet that exploitation condition.
What is the remediation?
Upgrade Dancer2 to version 2.2.0 or later. That release addresses CR and LF handling for response header names in headers_to_array.