Dancer2 Perl Framework Multiple Vulnerabilities

Unauthenticated path traversal in the Dancer2 Perl web framework (versions 2.1.0 up to but not including 2.2.0) lets a remote attacker read arbitrary files that the worker process can access, including configuration files such as config.yml stored above public_dir. The flaw only manifests in a non-default deployment where the application names File in its route_handlers configuration and sets static_handler to 0 - because the default static handler refuses dot segments before the File route executes; applications left at defaults are not affected. The vendor has released Dancer2 2.2.0 with a containment fix, EPSS is low (0.19%, 8th percentile), and no public exploit code or confirmed active exploitation was identified at time of analysis.

Security-control bypass in the Dancer2 Perl web framework (2.0.0 through 2.1.x) lets a refused route execute anyway: when an application enforces an authorization or security check by having a 'before' hook die and also registers an on_hook_exception handler that halts the response, the post-exception cleanup still runs and destroys the request, response and session the dispatcher needs, so the route body the hook meant to refuse runs and its writes land. The flaw requires that specific non-default application design - apps that do not refuse via dying hooks, or whose exception handler does not halt the response, are not affected - and, when the pattern is present, a single unauthenticated remote request is enough to trigger it (AV:N/AC:L/PR:N/UI:N), giving a high integrity impact on denial-protected state changes. EPSS is 0.17% (7th percentile) and there is no public exploit identified at time of analysis; CISA's SSVC rates exploitation as none, automatable as yes, technical impact partial. Vendor-released patch: Dancer2 2.2.0, which adds a halt check to the cleanup guard and makes hook compilation idempotent.

HTTP response splitting in the Dancer2 Perl web framework before version 2.2.0 allows an attacker to inject arbitrary response headers and split an HTTP response when an application derives a response header NAME from request-controlled data: Dancer2's headers_to_array routine strips CR and LF from header values but not from names, so a crafted name reaches the PSGI server intact and, if that server does not validate header keys, the bytes following the CRLF are written to the wire as their own header line. The issue is unauthenticated and requires no user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N, 6.5 Medium), but exploitation is gated by two concrete application-specific preconditions - the app must reflect attacker input into a header key rather than a value, and the underlying PSGI server must fail to reject malformed keys - so default deployments are generally not vulnerable. No CISA KEV entry exists and no public exploit code was identified at time of analysis; EPSS is 0.19% (9th percentile) and CISA SSVC records exploitation as none and automatable exploitation as no, so all signals converge on low real-world priority despite the Medium CVSS.

Layout template disclosure in Dancer2, the Perl web application framework, allows an unauthenticated remote requester to retrieve one of an application's layout templates by requesting a path that is spelled differently from, but resolves identically to, the layout directory. Versions before 2.2.0 are affected, and the flaw is reachable only when the AutoPage handler is explicitly turned on via the auto_page setting, which is off by default; the attacker exploits the gap between the handler's literal text comparison of the request path and the canonicalising lookup that follows, using a doubled slash, a dot segment, a percent-encoded slash, or a differently-cased path on a case-insensitive filesystem. Impact is confined to reading another layout template - no code execution, no credentials, no write access - and no public exploit code has been identified at time of analysis, with EPSS at 0.19% (8th percentile).