CVE-2026-75922: Reverse::Proxy versions before 0.04 for Perl allow HTTP request smuggling via a percent-decoded PATH_INFO written unencoded to the upstream request line
Reverse::Proxy versions before 0.04 for Perl allow HTTP request smuggling via a percent-decoded PATHINFO written unencoded to the upstream request line.
PSGI hands PATHINFO to an application percent-decoded, so a %XX sequence in the client URL has become a raw byte by the time the proxy sees it. The proxy appends that byte string to the upstream base URL, and for an Upgrade tunnel writes it into a request line it serializes itself, re-encoding nothing in either path. The HTTP client that sends the resulting URL does not validate the target either. A path containing %0d%0a therefore arrives at the upstream as a CRLF that ends the request line, and a decoded space, '?' or '#' truncates it the same way.
Everything the client writes after the CRLF is read by the upstream as a second request. On the buffered path it arrives on a keep-alive connection the proxy pools and reuses for other clients. Its method, path and headers are all chosen by the client, and the upstream attributes it to the proxy, so it reaches upstream paths that the proxy's own routing does not expose.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Reverse::Proxyto a version that resolves this vulnerability.Fixed in 0.04
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using Perl Reverse::Proxy versions earlier than 0.04 are affected when attacker-controlled request paths are forwarded upstream. Both the buffered forwarding path and Upgrade tunnel handling are described as vulnerable.
What does an attacker need to exploit it?
An attacker needs to send a request whose path contains percent-encoded characters that become unsafe after PSGI decodes PATH_INFO, such as %0d%0a. The proxy forwards the decoded bytes without re-encoding or validating the upstream request target.
What is the practical impact of successful exploitation?
The attacker can cause an upstream server to interpret injected data as a second HTTP request with an attacker-chosen method, path, and headers. On the buffered path, that request is sent over a pooled keep-alive connection and can reach upstream paths not exposed by the proxy's routing.
How can exposure be reduced if upgrading is not immediately possible?
The provided information identifies the unsafe condition as percent-decoded PATH_INFO being written into the upstream request target without encoding or validation. Preventing requests with encoded CRLF, spaces, question marks, or hash characters from reaching the proxy would reduce exposure, but the data does not provide a complete workaround.