Nateberkopec

Name of the Vulnerable Software and Affected Versions: Puma versions prior to 6.4.3 Puma versions prior to 5.6.9 Description: The issue is related to the handling of HTTP requests in Puma, a Ruby/Rack web server. Clients could overwrite values set by intermediate proxies, such as X-Forwarded-For, by providing an underscore version of the same header, for example, X-Forwarded For. This could allow an attacker to downgrade connections to HTTP or redirect responses, potentially causing confidentiality leaks. Users relying on proxy-set variables are affected. Recommendations: For Puma versions prior to 6.4.3, upgrade to version 6.4.3 or later. For Puma versions prior to 5.6.9, upgrade to version 5.6.9 or later. As a temporary workaround, consider using Nginx's underscores in headers configuration variable to discard headers with underscores at the proxy level. Any users implicitly trusting proxy-defined headers for security should immediately cease doing so until upgraded to the fixed versions.

**Name of the Vulnerable Software and Affected Versions** Puma versions prior to 5.6.2 Puma version 4.3.11 Rails versions prior to 7.0.2.2 Rails versions prior to 6.1.4.6 Rails versions prior to 6.0.4.6 Rails versions prior to 5.2.6.2 **Description** The issue is related to information leakage due to Puma not always calling `close` on the response body and Rails depending on the response body being closed for its `CurrentAttributes` implementation to work correctly. This combination of behaviors causes information leakage. The problem can be exploited by an attacker to gain access to confidential information. **Recommendations** For Puma versions prior to 5.6.2, upgrade to version 5.6.2 or 4.3.11. For Rails versions prior to 7.0.2.2, upgrade to version 7.0.2.2. For Rails versions prior to 6.1.4.6, upgrade to version 6.1.4.6. For Rails versions prior to 6.0.4.6, upgrade to version 6.0.4.6. For Rails versions prior to 5.2.6.2, upgrade to version 5.2.6.2. As a temporary workaround, consider using the provided middleware to guard against the issue.

**Name of the Vulnerable Software and Affected Versions** Puma versions prior to 3.12.2 Puma versions prior to 4.3.1 **Description** A poorly-behaved client could use keepalive requests to monopolize Puma's reactor and create a denial of service attack. If more keepalive connections to Puma are opened than there are threads available, additional connections will wait permanently if the attacker sends requests frequently enough. **Recommendations** For versions prior to 3.12.2, update to version 3.12.2 or later to resolve the issue. For versions prior to 4.3.1, update to version 4.3.1 or later to resolve the issue. As a temporary workaround, consider configuring reverse proxies in front of Puma to always allow less than X keepalive connections to a Puma cluster or process, where X is the number of threads configured in Puma's thread pool.

Name of the Vulnerable Software and Affected Versions: Puma versions prior to 4.3.2 Puma versions prior to 3.12.3 Description: The issue is related to HTTP Response Splitting, where an attacker can use newline characters (`CR`, `LF`, or `/r`, `/n`) to end a header and inject malicious content, such as additional headers or a new response body. This can be a vector for other attacks, including cross-site scripting (XSS). Recommendations: For versions prior to 4.3.2, update to version 4.3.2 or later. For versions prior to 3.12.3, update to version 3.12.3 or later. As a temporary workaround, consider restricting untrusted input in response headers to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Puma versions prior to 5.5.1 and 4.3.9 **Description** The issue is related to HTTP request smuggling when using Puma with a proxy that forwards HTTP header values containing the LF character. This could allow a client to smuggle a request through a proxy, causing the proxy to send a response back to another unknown client. The only proxy known to have this behavior is Apache Traffic Server. If the proxy uses persistent connections and the client adds another request via HTTP pipelining, the proxy may mistake it as the first request's body. Puma, however, would see it as two requests, and when processing the second request, send back a response that the proxy does not expect. If the proxy has reused the persistent connection to Puma to send another request for a different client, the second response from the first client will be sent to the second client. **Recommendations** To resolve the issue, update to Puma version 5.5.1 or 4.3.9. As a temporary workaround, do not use Apache Traffic Server with Puma. Consider using a proxy that does not forward LF characters as line endings, such as Nginx, Apache (>2.4.25), Haproxy, Caddy, or Traefik.

**Name of the Vulnerable Software and Affected Versions** Puma versions prior to 3.12.6 Puma versions prior to 4.3.5 **Description** A client could smuggle a request through a proxy, causing the proxy to send a response back to another unknown client. If the proxy uses persistent connections and the client adds another request in via HTTP pipelining, the proxy may mistake it as the first request's body. Puma, however, would see it as two requests, and when processing the second request, send back a response that the proxy does not expect. If the proxy has reused the persistent connection to Puma to send another request for a different client, the second response from the first client will be sent to the second client. **Recommendations** For versions prior to 3.12.6, update to Puma 3.12.6 to resolve the issue. For versions prior to 4.3.5, update to Puma 4.3.5 to resolve the issue. As a temporary workaround, consider disabling HTTP pipelining until a patch is available. Restrict access to the proxy to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Puma versions prior to 4.3.12 Puma versions prior to 5.6.4 **Description** The issue is related to the handling of HTTP requests in Puma, a server for Ruby/Rack applications. When Puma is used behind a proxy that does not properly validate incoming HTTP requests according to the RFC7230 standard, it may lead to a disagreement between Puma and the frontend proxy on where a request starts and ends. This can allow requests to be smuggled via the front-end proxy to Puma. The vulnerability is associated with lenient parsing of `Transfer-Encoding` headers, `Content-Length` headers, and chunk sizes, as well as the ending of chunked segments. **Recommendations** For Puma versions prior to 4.3.12, upgrade to version 4.3.12 or later. For Puma versions prior to 5.6.4, upgrade to version 5.6.4 or later. As a temporary workaround, when deploying a proxy in front of Puma, turn on any and all functionality to ensure that the request matches the RFC7230 standard. Consider using proxy servers known to have "good" behavior regarding this standard, such as Nginx, Apache, Haproxy 2.5+, Caddy, or Traefik, to minimize the risk of exploitation.