Hello, On Wed, Nov 26, 2025 at 11:01:07AM +0800, Kenny Cheng wrote: > The vulnerability arises from HAProxy's non-compliance with relevant RFC > specifications when processing HTTP requests. According to RFC standards > (RFC9112#section-3.2.2), if an HTTP request contains an absolute-uri, the > Host value should be derived from that absolute-uri. However, HAProxy fails > to implement this specification correctly in certain configurations. > > In typical deployment architectures where HAProxy forwards HTTP traffic to a > reverse proxy server by default, and the reverse proxy distributes requests > to different backend application servers based on domain names, this > vulnerability can be exploited. When HAProxy is configured to block access > to a specific domain (via blacklist), attackers can construct an HTTP 1.0 > request that omits the Host Header but includes an absolute-uri pointing to > the blacklisted domain. Due to HAProxy's non-compliance with RFC, it does > not correctly identify the target domain from the absolute-uri, thus failing > to trigger the blacklist restriction and allowing the request to bypass the > block and reach the target backend server.
HTTP/1.0 is defined by RFC1945 and it's the last RFC covering this version. The Host header is not specified in HTTP/1.0, is not mandatory at all and not required to match the authority part of the URI. Host was only standardized in HTTP/1.1 with RFC2068, so it would be totally inappropriate to require a valid Host header to be present in an HTTP/1.0 request or to match the authority part. In HTTP/1.0 the authority was only used in requests sent to proxies and there was no requirement that a server would accept them at all. Hoping this helps, Willy
