Summary

rack-proxy 1.0.0 through 1.0.2 can forward an incorrect Content-Length when a backend response contains both Transfer-Encoding and Content-Length. Net::HTTP removes chunked framing from the body, while rack-proxy strips Transfer-Encoding but retains the backend-supplied Content-Length. This affects both the default streaming mode and streaming: false.

Impact and Preconditions

A malicious, compromised, or attacker-influenced backend can supply a length shorter than the dechunked body. When a frontend Rack handler trusts this length and uses persistent connections, surplus bytes can be interpreted as a subsequent HTTP response, allowing response-queue poisoning and potentially affecting intermediaries or caches.

The reporter demonstrated downstream desynchronization with WEBrick 1.9.2 via Rackup::Handler. Other handlers may close or reframe the response; end-to-end exploitability depends on the deployment. The inconsistent Rack response was confirmed in both streaming modes. No opt-in setting is needed for the vulnerable response handling.

Credit

Thanks to oss-security-shop for privately reporting the vulnerability and providing a detailed reproduction.