Régis Leroy

**Name of the Vulnerable Software and Affected Versions** Apache HTTP Server versions 2.4.53 and earlier **Description** The issue is related to the mod proxy module in Apache HTTP Server, which may not properly handle X-Forwarded-* headers based on the client-side Connection header hop-by-hop mechanism. This could allow a remote attacker to bypass IP-based authentication on the origin server or application. **Recommendations** For Apache HTTP Server versions 2.4.53 and earlier, consider updating to a version that includes the fix for this issue, as the current version may not send the X-Forwarded-* headers to the origin server based on the client-side Connection header hop-by-hop mechanism, potentially allowing IP-based authentication bypass. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

Name of the Vulnerable Software and Affected Versions: Squid versions prior to 4.13 Squid versions 5.x prior to 5.0.4 Description: An issue was discovered due to incorrect data validation, allowing HTTP Request Splitting attacks to succeed against HTTP and HTTPS traffic. This leads to cache poisoning, enabling any client, including browser scripts, to bypass local security and poison the browser cache and any downstream caches with content from an arbitrary source. The issue arises because Squid uses a string search instead of parsing the `Transfer-Encoding` header to find chunked encoding, allowing an attacker to hide a second request inside `Transfer-Encoding`. This is interpreted by Squid as chunked and split out into a second request delivered upstream, resulting in Squid delivering two distinct responses to the client and corrupting any downstream caches. The vulnerability is also related to the lack of processing of CRLF sequences in HTTP headers. Recommendations: For Squid versions prior to 4.13, update to version 4.13 or later. For Squid versions 5.x prior to 5.0.4, update to version 5.0.4 or later. As a temporary workaround, consider restricting access to the `Transfer-Encoding` header to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Squid versions 3.x through 4.8 **Description** The issue allows attackers to smuggle HTTP requests through frontend software to a Squid instance, corrupting caches with attacker-controlled content at arbitrary URLs. This is related to a request header containing whitespace between a header name and a colon. The effects are isolated to software between the attacker client and Squid, with no effects on Squid itself or any upstream servers. The vulnerability is associated with a lack in the interpretation of HTTP requests, which can be exploited by a remote attacker to impact data integrity. **Recommendations** For Squid versions 3.x through 4.8, consider restricting access to the vulnerable request header processing mechanism until a patch is available. As a temporary workaround, avoid using request headers with whitespace between the header name and a colon to minimize the risk of exploitation. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Apache HTTP Server versions prior to 2.2.32 and 2.4.25 **Description** The issue is related to the improper handling of data by the Apache HTTP Server, which was liberal in accepting whitespace from requests and sending it in response lines and headers. This behavior poses a security concern when the server participates in a chain of proxies or interacts with back-end application servers, potentially leading to request smuggling, response splitting, and cache pollution. **Recommendations** For versions prior to 2.2.32 and 2.4.25, update to version 2.2.32 or 2.4.25, or later, which includes the new directive HttpProtocolOptions Strict to address these defects. As a temporary workaround, consider using the HttpProtocolOptions directive with the Strict option to enforce stricter HTTP protocol compliance. Restrict access to the server until the update can be applied to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Varnish versions 3.x through 3.0.6 **Description** The issue allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via a header line terminated by a r (carriage return) character in conjunction with multiple Content-Length headers in an HTTP request. This occurs when Varnish is used in certain stacked installations. **Recommendations** For Varnish versions 3.x through 3.0.6, update to version 3.0.7 or later to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** Node.js versions 0.10.x through 0.10.41 Node.js versions 0.12.x through 0.12.9 Node.js versions 4.x through 4.2.0 Node.js versions 5.x through 5.5.0 **Description** The issue allows remote attackers to conduct HTTP request smuggling attacks via a crafted `Content-Length` HTTP header. **Recommendations** For Node.js versions 0.10.x through 0.10.41, update to version 0.10.42 or later. For Node.js versions 0.12.x through 0.12.9, update to version 0.12.10 or later. For Node.js versions 4.x through 4.2.0, update to version 4.3.0 or later. For Node.js versions 5.x through 5.5.0, update to version 5.6.0 or later.

**Name of the Vulnerable Software and Affected Versions** Go versions prior to 1.4.3 **Description** The issue arises from improper parsing of HTTP headers, allowing remote attackers to conduct HTTP request smuggling attacks. This can be achieved via a request that contains `Content-Length` and `Transfer-Encoding` header fields. **Recommendations** For versions prior to 1.4.3, update to version 1.4.3 or later to resolve the issue. As a temporary workaround, consider restricting access to the net/http library until a patch is applied. Avoid using the `Content-Length` and `Transfer-Encoding` header fields in requests to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Go versions prior to 1.4.3 **Description** The issue arises from improper parsing of HTTP header keys in the net/http library, specifically when a space is used instead of a hyphen, as seen in "Content Length" instead of "Content-Length". This allows remote attackers to conduct HTTP request smuggling attacks via a request that contains `Content-Length` and `Transfer-Encoding` header fields. **Recommendations** For Go versions prior to 1.4.3, update to version 1.4.3 or later to resolve the issue. As a temporary workaround, consider restricting access to the `net/http` library until a patch is applied. Avoid using the `Content-Length` and `Transfer-Encoding` header fields in the affected API endpoints until the issue is resolved.

Name of the Vulnerable Software and Affected Versions: Go versions prior to 1.4.3 Description: The issue is related to the improper parsing of HTTP headers in the net/http library, which allows remote attackers to conduct HTTP request smuggling attacks. This can be achieved via a request that contains `Content-Length` and `Transfer-Encoding` header fields. Recommendations: For Go versions prior to 1.4.3, update to version 1.4.3 or later to resolve the issue. As a temporary workaround, consider restricting access to the net/http library until a patch is applied. Avoid using the `Content-Length` and `Transfer-Encoding` header fields in requests to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Apache HTTP Server versions prior to 2.4.14 **Description** The issue is related to the improper parsing of chunk headers in the chunked transfer coding implementation, allowing remote attackers to conduct HTTP request smuggling attacks via a crafted request. This is due to the mishandling of large chunk-size values and invalid chunk-extension characters in the modules/http/http filters.c module. A malicious client could force the server to misinterpret the request length, potentially allowing cache poisoning or credential hijacking if an intermediary proxy is in use. **Recommendations** For Apache HTTP Server versions prior to 2.4.14, update to version 2.4.14 or later to resolve the issue. As a temporary workaround, consider restricting access to the vulnerable module modules/http/http filters.c to minimize the risk of exploitation. Avoid using the chunked transfer coding implementation until the issue is resolved.