I will attach the patch to this flaw, but there may be an even newer patch available from the reporter (Willy Tarreau). Summary from the initial report: There is a serious bug in haproxy's HTTP/1 header parser which unfortunately accepts an empty header name ... The impact is that some mandatory headers could be dropped after their presence was confirmed ... resulting in a request smuggling attack. Also this empty header could be used to make a transfer-encoding or content-length disappear while the internal parser still thinks it's there since it was seen ... I guess some (attackers) might be creative enough to exploit it ... The fix ... applies well as far as v2.0 ... I would like to propose an early coordinated release date ... Tuesday 14th 7pm CET ... it shouldn't take long to some attackers to figure how to exploit this to bypass some URL checks
Created haproxy tracking bugs for this issue: Affects: fedora-all [bug 2169823]
Created haproxy18 tracking bugs for this issue: Affects: epel-all [bug 2170060]
When can we expect you to release a patched version. Today it's 3 weeks since CVE-2023-25725 was published
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.12 Via RHSA-2023:1268 https://access.redhat.com/errata/RHSA-2023:1268
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2023:1696 https://access.redhat.com/errata/RHSA-2023:1696
This issue has been addressed in the following products: Red Hat Enterprise Linux 9.0 Extended Update Support Via RHSA-2023:1978 https://access.redhat.com/errata/RHSA-2023:1978
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.13 Via RHSA-2023:1325 https://access.redhat.com/errata/RHSA-2023:1325
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2023-25725
Increasing this impact to Important after reconsideration. While the difficulty of creating an effective attack on sites behind HAProxy is largely dependent on the site's architecture, the difficulty to affect the Integrity of specially crafted data passed through HAProxy itself is low.
Why do you consider RHEL 8 at https://access.redhat.com/security/cve/cve-2023-25725 to be "not affected"? As per https://security-tracker.debian.org/tracker/CVE-2023-25725, Debian backported the fix for this vulnerability to HAProxy 1.8 (included in 1.8.19-1+deb10u4). > The fix ... applies well as far as v2.0 ... If this is the cause, then I would like to remind that HAProxy 1.8 reached its end-of-life in Q4/2022 at upstream, see https://www.haproxy.org/. From my understanding upstream does not evaluate the applicability of security flaws for unmaintained HAProxy releases (this one was raised in Q1/2023).
See also: https://www.mail-archive.com/haproxy@formilux.org/msg43229.html > The problem affects all versions at different degrees: […] non-HTX versions (1.9 and before, or 2.0 in legacy mode) will not drop the theader, but will nonetheless pass the faulty request as-is to a server. This means that, while such versions will not be abused to attack a server, if placed at the edge they are not sufficient to protect an internal HAProxy instance either.
This issue has been addressed in the following products: Red Hat Ceph Storage 5.3 Via RHSA-2024:0746 https://access.redhat.com/errata/RHSA-2024:0746