HAProxy before 2.8.2 accepts # as part of the URI component, which might allow remote attackers to obtain sensitive information or have unspecified other impact upon misinterpretation of a path_end rule, such as routing index.html#.png to a static server. https://git.haproxy.org/?p=haproxy.git%3Ba=commit%3Bh=2eab6d354322932cfec2ed54de261e4347eca9a6 https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0070.html https://www.mail-archive.com/haproxy%40formilux.org/msg43861.html
Created haproxy tracking bugs for this issue: Affects: fedora-all [bug 2253038]
Per the HAProxy release notes: the URL fragments (the part that follows '#') are not allowed to be sent on the wire, and their handling on the server side has long been ambiguous. Historically most servers would trim them, nowadays with stronger specification requirements most of them tend to simply reject the request as invalid. Till now we did neither of these, so they could appear at the end of the "path" sample fetch contents. It can be problematic in case path_end is used to route requests. For example, a rule doing routing "{ path_end .png .jpg }" to a static server could very well match "index.html#.png". The question of how best to proceed in this case was asked to other HTTP implementers and the consensus was clearly that this should be actively rejected, which is even specifically mandated in certain side-protocol specs. A measurement on haproxy.org shows that such requests appear at a rate of roughly 1 per million, and are either emitted by poorly written crawlers that copy-paste blocks of text, or are sent by vulnerability scanners. Thus a check was added for this corner case which is now blocked by default. In case anyone would discover that they're hosting a bogus application relying on this, this can be reverted using "option accept-invalid-http-request".
This issue has been addressed in the following products: Red Hat Enterprise Linux 9.2 Extended Update Support Via RHSA-2024:1089 https://access.redhat.com/errata/RHSA-2024:1089
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2024:1142 https://access.redhat.com/errata/RHSA-2024:1142