Mattias Grenfeldt

**Name of the Vulnerable Software and Affected Versions** Apache Traffic Server versions 8.0.0 through 8.1.2 Apache Traffic Server versions 9.0.0 through 9.0.1 **Description** The issue is related to improper input validation in the header parsing of Apache Traffic Server, allowing an attacker to smuggle requests. **Recommendations** For Apache Traffic Server versions 8.0.0 through 8.1.2, update to a version outside of this range to resolve the issue. For Apache Traffic Server versions 9.0.0 through 9.0.1, update to a version outside of this range to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** Apache Traffic Server versions 8.0.0 through 8.1.2 Apache Traffic Server versions 9.0.0 through 9.1.0 **Description** The issue is related to improper input validation in the header parsing of Apache Traffic Server, allowing an attacker to smuggle requests. **Recommendations** For Apache Traffic Server versions 8.0.0 through 8.1.2, update to a version outside of this range to resolve the issue. For Apache Traffic Server versions 9.0.0 through 9.1.0, update to a version outside of this range to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** hyper versions prior to 0.14.10 **Description** The issue is related to the incorrect parsing and acceptance of requests with a `Content-Length` header containing a prefixed plus sign. This can lead to "request smuggling" or "desync attacks" when combined with an upstream HTTP proxy that does not parse such headers but forwards them. The estimated likelihood of an attack exploiting this vulnerability is considered low due to the specific conditions required. **Recommendations** For versions prior to 0.14.10, consider the following workarounds: - Reject requests manually that contain a plus sign prefix in the `Content-Length` header. - Ensure any upstream proxy handles `Content-Length` headers with a plus sign prefix. For a permanent fix, update to version 0.14.10 or later.

**Name of the Vulnerable Software and Affected Versions** hyper versions prior to 0.14.10 **Description** The issue is related to an integer overflow when decoding chunk sizes that are too big, which can trigger data loss or, in certain cases, "request smuggling" or "desync attacks" if combined with an upstream HTTP proxy that allows larger chunk sizes. This can occur when using hyper for any HTTP/1 purpose, including as a client or server, and consumers send requests or responses that specify a chunk size greater than 18 exabytes. For a possible request smuggling attack to be possible, any upstream proxies must accept a chunk size greater than 64 bits. **Recommendations** To resolve the issue, upgrade to version 0.14.10 or later. As a temporary workaround, consider rejecting requests manually that contain a `Transfer-Encoding` header. Alternatively, ensure any upstream proxy rejects `Transfer-Encoding` chunk sizes greater than what fits in 64-bit unsigned integers.

**Name of the Vulnerable Software and Affected Versions** Go versions 1.15.12 and earlier Go versions 1.16.x before 1.16.5 **Description** The issue is related to the ReverseProxy component from net/http/httputil in the Go programming language, which can result in a situation where an attacker can drop arbitrary headers. This can occur when the ReverseProxy is configured in a certain way, allowing an attacker to influence the integrity of data. The vulnerability can be exploited by a remote attacker. **Recommendations** For Go versions 1.15.12 and earlier, update to version 1.15.13 or later. For Go versions 1.16.x before 1.16.5, update to version 1.16.5 or later. As a temporary workaround, consider restricting the use of the ReverseProxy component until a patch is available.

**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.