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
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.15 Via RHSA-2024:4853 https://access.redhat.com/errata/RHSA-2024:4853
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.14 Via RHSA-2024:6412 https://access.redhat.com/errata/RHSA-2024:6412
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.6 Update Services for SAP Solutions Red Hat Enterprise Linux 8.6 Telecommunications Update Service Via RHSA-2024:8874 https://access.redhat.com/errata/RHSA-2024:8874
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:8849 https://access.redhat.com/errata/RHSA-2024:8849
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Advanced Update Support Via RHSA-2024:9945 https://access.redhat.com/errata/RHSA-2024:9945
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.8 Extended Update Support Via RHSA-2024:10267 https://access.redhat.com/errata/RHSA-2024:10267
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions Red Hat Enterprise Linux 8.4 Telecommunications Update Service Via RHSA-2024:10271 https://access.redhat.com/errata/RHSA-2024:10271