Dancer2 CVE-2026-93711

Exploitation requires two concrete conditions from the description, not raw network reachability: (1) the Dancer2 application must construct a response header NAME from request-controlled data (reflecting attacker input into the header key, not just the value), and (2) the underlying PSGI server must not validate/reject header keys, so the CRLF-bearing name is written verbatim to the wire. Affected versions are Dancer2 before 2.2.0. Because Dancer2 strips CR/LF from header values but not names, apps that only reflect data into header values are NOT affected. There is no user-interaction or authentication requirement (PR:N/UI:N), but the app-specific header-name-derivation pattern is the real limiting factor and makes default deployments generally not vulnerable.

All signals converge on LOW real-world priority despite the MEDIUM 6.5 CVSS. The vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N indicates remote, unauthenticated, low-complexity access, but every corroborating exploitation signal is cold: EPSS is 0.19% (9th percentile), there is no CISA KEV listing, no public exploit code is referenced, and CISA SSVC scores Exploitation=none, Automatable=no, Technical Impact=partial. The most important limiter is not in the CVSS base score at all: the flaw is only reachable when the application derives a response HEADER NAME (not merely a value) from attacker-controlled request data AND the underlying PSGI server does not validate header keys - an uncommon coding pattern. So although the base metrics read 'unauthenticated network', the true attack surface is narrow and application-specific. This is a legitimate correctness bug (CR/LF stripped from header values but not names in Dancer2::Core::Response::headers_to_array) worth patching in the normal cycle, not an emergency. No conflicting data: the CVSS, EPSS, SSVC, and absence of KEV/POC all agree this is low-urgency.

A Dancer2 (<2.2.0) application reflects a piece of user-supplied request data into a response header NAME. An unauthenticated attacker supplies that data with an embedded CRLF sequence followed by attacker-chosen header lines; because headers_to_array strips CR/LF only from values, the name reaches a non-validating PSGI server intact and the injected bytes are written to the wire as separate header lines, splitting the response. No public exploit code is referenced and exploitation still depends on the app-specific header-name reflection pattern.