Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN689 _____________________________________________________________________ DATE : 29/06/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running HAProxy Enterprise versions prior to 1.0.0-308.1822, 2.8r1-341.1462, 3.0r1-360.1200, 3.2r1-376.966, 3.3r1-375.672, HAProxy Community Edition All supported branches, HAProxy ALOHA versions prior to 14.5.46, 15.5.45, 16.5.39, 17.5.29, 18.0.8. ===================================================================== https://www.haproxy.com/blog/june-2026-cve-2026-55204-null-pointer-dereference-in-haproxys-hpack-header-handling _____________________________________________________________________ June 2026 – CVE-2026-55204: null pointer dereference in HAProxy's HPACK header handling On June 18, 2026, CVE-2026-55204 was published, reported by security researcher Tristan Madani and filed through a third-party CNA. It describes a null pointer dereference in HAProxy's HPACK (HTTP/2 header compression) handling: the hpack_dht_insert() function in src/hpack-tbl.c does not check the return value of hpack_dht_defrag() when the memory pool is exhausted, which can cause a process to crash if other OOM or other system stability issues do not already cause the instance to crash. That could result in a denial-of-service attack. The report carries a CVSS v4.0 score of 8.7 (High). We want to be transparent about that score and equally clear about our assessment: the real-world risk is low. This is not realistically exploitable. The issue was observed only on a custom-modified HAProxy build, and neither our team nor the reporter was able to reproduce it on a standard build. There is no known proof-of-concept and no evidence of exploitation in the wild. The CVSS vector also reflects an availability-only impact (a process crash) with no impact to confidentiality or integrity. The reason comes down to how modern systems manage memory. Triggering this bug requires an allocation to return NULL under memory exhaustion. Still, on a normally configured Linux system, the kernel's out-of-memory (OOM) killer terminates a memory-starved process before that can happen. Returning NULL in this path generally requires a non-default memory-overcommit configuration that very few deployments use. In practice, a server would already be in a critical low-memory state before this code path could be reached. We committed a fix regardless, out of respect for the report and to keep our codebase clean, and we are rolling it out through our normal release process rather than as an emergency patch. We recommend customers update to a fixed version once it is available for their product. In the meantime, the most effective safeguard is the one we recommend for any production deployment: size HAProxy to the memory available on its host so the process does not approach Out-of-Memory (OOM) conditions. Vulnerability details CVE Identifier: CVE-2026-55204 CVSS v4.0 Score: 8.7 (High) — base score assigned by the CNA (VulnCheck) Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N For reference, the equivalent CVSS v3.1 base score is 7.5 (High): CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Weakness: CWE-476 (NULL Pointer Dereference) Affected component: HAProxy HPACK dynamic header table — hpack_dht_insert() in src/hpack-tbl.c Reported by: Tristan Madani Published: June 18, 2026 (CVE source: VulnCheck) Description: The issue was first reported to HAProxy Community Edition as a minor bug, demonstrated using a custom version of HAProxy. hpack_dht_insert() does not validate the return value of hpack_dht_defrag() when the memory pool is exhausted. HPACK dynamic table insertions under memory pressure can dereference a null pointer, crashing HAProxy worker processes and causing a denial-of-service. HAProxy Technologies was unable to reproduce the bug with a standard version of HAProxy, and has no evidence of exploitation. CISA's automated SSVC assessment also records exploitation status as "none." Because the trigger is memory-pool exhaustion, deployments with insufficient memory (reaching OOM or similar states) are most relevant to this issue. HAProxy's assessment Based on our analysis, we do not consider this a meaningful avenue for attacking or weakening HAProxy services. A rolling release is typical for HAProxy Enterprise patches addressing low-risk issues: fixes flow continuously from HAProxy Community Edition and are picked up for upcoming HAProxy Enterprise releases and backports. We are publishing this advisory because a CVE with a high CVSS score has been filed, and we want customers to have the full picture (both the score and our assessment) so they can make an informed decision about when to update. Affected versions and remediation This issue is present across currently supported versions of HAProxy — the CVE record cites all releases up to and including 3.4.0, so it is not limited to the latest branch. Because the affected code is part of the core HTTP/2 engine, products built on HAProxy (HAProxy Community Edition, HAProxy Enterprise, and HAProxy ALOHA) should be assumed in scope. The fix is committed upstream in commit 9a6d1fe. At the time of writing, the fix has not yet been included in a tagged HAProxy Community Edition release — it is available in source for anyone who wishes to compile it themselves — and HAProxy Enterprise packages and builds are being rebuilt now. The HAProxy Community Edition team is targeting a tagged release in its next release series The issue is fixed in HAProxy Enterprise after the following builds: Product Branch Fixed after build HAProxy Enterprise hapee-2.6r1 1.0.0-308.1822 HAProxy Enterprise hapee-2.8r1 2.8r1-341.1462 HAProxy Enterprise hapee-3.0r1 3.0r1-360.1200 HAProxy Enterprise hapee-3.2r1 3.2r1-376.966 HAProxy Enterprise hapee-3.3r1 3.3r1-375.672 HAProxy Community Edition All supported branches Pending tagged release (committed upstream) HAProxy ALOHA 14.5 14.5.46 HAProxy ALOHA 15.5 15.5.45 HAProxy ALOHA 16.5 16.5.39 HAProxy ALOHA 17.5 17.5.29 HAProxy ALOHA 18.0 18.0.8 The permanent fix is delivered by updating to a patched version. In the meantime, the most effective safeguard is the one we recommend for any production deployment: size HAProxy to the memory available on its host so the process does not approach Out-of-Memory conditions. A system kept within healthy memory limits will not reach the state required to trigger this issue. Upgrade instructions Once fixed images are available, users of affected products should update by pulling the latest version for their respective release track. Instructions are linked below (customer login required): Upgrade HAProxy Enterprise Upgrade HAProxy Enterprise with HAProxy Fusion Upgrade HAProxy ALOHA HAProxy Community Edition: update to the fixed tagged release once published, or build from source. Support If you are an HAProxy customer with questions about this advisory or about upgrading to the latest version, please contact our support team. ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================