Reverse::Proxy CVE-2026-75922

Exploitation requires that the target deploy Reverse::Proxy (Perl CPAN) in version 0.03 or earlier within a PSGI-compliant application stack - any conforming PSGI server (Plack/PSGI, Starman, Twiggy) will percent-decode PATH_INFO as the specification requires, satisfying the precondition. No non-default configuration, authentication, or special feature flag is needed; the decoding behaviour is mandatory per the PSGI spec and cannot be disabled. The PR:N/AC:L CVSS metrics confirm unauthenticated, low-complexity exploitation over the network. The cross-client session poisoning variant additionally requires that the proxy reuse upstream keep-alive connections across client requests, which is standard behaviour for the buffered code path. Exploitation is limited in breadth by the niche deployment footprint of this module and by the fact that the injected request's impact is bounded by what the upstream server exposes on its internal interface; if the upstream requires its own authentication for sensitive paths, attacker impact is reduced to information disclosure via observable response timing or error messages.

The NVD CVSS 5.3 score (Medium, AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) understates real-world impact: it scores scope as unchanged and integrity as none, yet the described attack reaches upstream paths outside the proxy's routing boundary - a scope change - and can POST attacker-chosen payloads to those paths - an integrity impact. My independent assessment (see assessed_cvss_vector) revises those metrics accordingly. EPSS sits at 0.26% (18th percentile), reflecting very low current exploitation probability, consistent with the SSVC exploitation status of none. However, SSVC also flags this as automatable, meaning a scanner could probe at scale without manual per-host effort. The technical impact is rated partial by SSVC: access is limited to what the upstream exposes on its internal interface, which may include admin endpoints or other restricted paths never intended to be externally reachable, making the realistic severity deployment-dependent. There is no KEV listing and no circulating public POC, so risk is currently theoretical. The narrow deployment footprint of a niche Perl CPAN module substantially limits breadth. The primary concern is organisations that use Reverse::Proxy to gate access to privileged upstream APIs, where a smuggled request bypassing the proxy's ACL layer could reach high-value endpoints.

An attacker sends a GET request to the proxy with a URL such as /legitimate%2fpath%0d%0aGET%20/admin%20HTTP/1.1%0d%0aHost:%20upstream-internal%0d%0a%0d%0a. The PSGI server decodes this to a raw PATH_INFO containing a CRLF sequence before the proxy processes it. The proxy appends the decoded bytes to the upstream request line verbatim, causing the upstream to parse the CRLF as the line terminator and treat the injected GET /admin HTTP/1.1 as a second, standalone request arriving on the same pooled keep-alive connection - a connection the upstream trusts as belonging to the proxy. No public POC exists, but the oss-security advisory and metacpan source references provide enough technical detail for a skilled attacker to reproduce the issue.