CVE-2026-93711: Dancer2 for Perl XSS Vulnerability

CVE-2026-93711 Overview

CVE-2026-93711 is an HTTP response splitting vulnerability [CWE-113] in the Dancer2 Perl web framework prior to version 2.2.0. The headers_to_array routine in Dancer2::Core::Response strips carriage return (CR) and line feed (LF) characters from header values but not from header names. When an application derives a header name from untrusted request data, an attacker can inject CRLF sequences into the name. A PSGI server that does not validate header keys writes the bytes to the wire, causing content after the CRLF to appear as separate response headers.

Critical Impact
Attackers who control data used to construct response header names can inject arbitrary headers and split HTTP responses, enabling cache poisoning and header manipulation.

Affected Products

Dancer2 for Perl, all versions before 2.2.0
PSGI applications using Dancer2::Core::Response with request-derived header names
Deployments behind PSGI servers that do not independently validate header keys

Discovery Timeline

2026-09-22 - CVE-2026-93711 published to NVD
2026-09-22 - Public discussion on OpenWall oss-security list
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-93711

Vulnerability Analysis

Dancer2 constructs the outbound header array by iterating over headers and pushing each name/value pair to a list. The value undergoes CRLF stripping to prevent response splitting, but the name receives no equivalent sanitization. Any application that assigns a header name derived from user input inherits the framework's trust that names are well-formed. The absence of validation allows an attacker to embed \r\n in the name field, terminating the current header line and starting new ones.

Downstream PSGI servers vary in how strictly they enforce RFC 7230 header field name syntax. Servers that pass names through without validation emit the malformed line, producing a genuine response-splitting condition. Consequences include injecting Set-Cookie headers, poisoning intermediate caches, and manipulating security headers such as Content-Security-Policy.

Root Cause

The defect is asymmetric input sanitization in lib/Dancer2/Core/Response.pm. The scan callback that builds the header array applied CRLF removal only to $v (value) and not to $k (key). The framework treated header names as trusted while treating values as untrusted, an assumption invalid whenever application code sets a header whose name comes from request data.

Attack Vector

The attack requires network access and no authentication or user interaction. The attacker submits a request whose parameters are used by the application to construct a response header name. The injected \r\n splits the response, allowing the attacker to append arbitrary headers or body content interpreted by clients and proxies as originating from the server.

text

     my @hdrs;
     $headers->scan( sub {
         my ( $k, $v ) = @_;
+         $k =~ s/\015\012[\040|\011]+/chr(32)/ge; # replace LWS with a single SP
+         $k =~ s/\015|\012//g; # remove CR and LF from the name for the same
+                                # reason as the value: an unsanitised name is
+                                # just as usable for response splitting
          $v =~ s/\015\012[\040|\011]+/chr(32)/ge; # replace LWS with a single SP
          $v =~ s/\015|\012//g; # remove CR and LF since the char is invalid here
         push @hdrs, $k => $v;

Source: GitHub Dancer2 Patch Commit. The patch adds CR/LF stripping and linear whitespace collapsing to the header name $k, matching the existing treatment of the value $v.

Detection Methods for CVE-2026-93711

Indicators of Compromise

HTTP response bodies or headers logged with embedded %0d%0a or literal CR/LF sequences in header name positions
Unexpected Set-Cookie, Location, or security-policy headers appearing in server logs for endpoints that echo request data
Cache entries at CDNs or reverse proxies containing duplicated or unexpected header lines tied to a single origin response

Detection Strategies

Review Dancer2 application source for calls that assign response header names from params, request->parameters, path segments, or query strings
Enable strict header validation at the PSGI server layer (for example, Starman, Twiggy, Gazelle) to reject names containing CR, LF, or non-token characters
Add web application firewall rules that block %0d, %0a, \r, and \n in request parameters that map to header-name assignments

Monitoring Recommendations

Ingest access logs and upstream proxy logs into a central analytics platform and alert on responses whose header count or size exceeds baseline
Monitor CDN and reverse proxy cache-key mismatches, which often indicate response splitting or smuggling
Track deployed Dancer2 versions across the estate and alert on any host running a release earlier than 2.2.0

How to Mitigate CVE-2026-93711

Immediate Actions Required

Upgrade Dancer2 to version 2.2.0 or later on all Perl application hosts
Audit application code for any location where response header names are set from untrusted input and remove or validate such patterns
Deploy a PSGI server or fronting proxy that rejects header names containing CR, LF, or other invalid token characters

Patch Information

The fix is committed to the Dancer2 repository in commit ff89ac12af7b8899812a79e9924dfea7a5d9833b and released in Dancer2 2.2.0. References: GitHub Dancer2 Issue #1822, MetaCPAN Dancer2 2.2.0 Changes, and OpenWall OSS Security Discussion.

Workarounds

Restrict response header names to a fixed allowlist within application code rather than deriving them from request data
Sanitize any dynamic header-name inputs by stripping \r, \n, and control characters before calling Dancer2 header-setting APIs
Place a hardened reverse proxy in front of the application that normalizes or drops responses containing malformed header lines

bash

# Upgrade Dancer2 via cpanm to the patched release
cpanm Dancer2@2.2.0

# Verify installed version
perl -MDancer2 -E 'say $Dancer2::VERSION'