惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Martin Fowler
Martin Fowler
WordPress大学
WordPress大学
S
SegmentFault 最新的问题
罗磊的独立博客
Apple Machine Learning Research
Apple Machine Learning Research
The Cloudflare Blog
L
LangChain Blog
博客园 - 司徒正美
G
Google Developers Blog
博客园 - 【当耐特】
GbyAI
GbyAI
月光博客
月光博客
人人都是产品经理
人人都是产品经理
D
DataBreaches.Net
大猫的无限游戏
大猫的无限游戏
A
About on SuperTechFans
Microsoft Azure Blog
Microsoft Azure Blog
V
Visual Studio Blog
D
Docker
MongoDB | Blog
MongoDB | Blog
Vercel News
Vercel News
Stack Overflow Blog
Stack Overflow Blog
Jina AI
Jina AI
博客园 - 聂微东

HAProxy Technologies

AI in the Public Sector (Infrastructure Challenges & Solutions) The big question at Black Hat USA 2026: How to enable post-quantum cryptography & TLS termination with HAProxy How Liftoff cut costs by 87% and latency by 75% with HAProxy AWS Summit London & NYC: what engineers want How Clover moved beyond blue-green deployments with HAProxy Fusion Control Plane Protecting against HTTP/2 Bomb vulnerability (CVE-2026-49975) with HAProxy Announcing HAProxy 3.4 Subsecond data center failover at Weller Truck Parts with HAProxy One HAProxy Enterprise WAF protects against Drupal core SA-CORE-2026-004 SQL Injection (CVE-2026-9082) How HAProxy built its modern application delivery architecture How Criteo handles 23M requests per second (RPS) with HAProxy Runtime API automation Announcing HAProxy Enterprise 3.3 and HAProxy ALOHA 18.0 How PayPal hyperscaled Kubernetes routing with HAProxy Fusion HAProxy at KubeCon Amsterdam 2026: the standard, by popular demand Announcing HAProxy Unified Gateway 1.0 Back to fundamentals: 7 insights from Kelsey Hightower at HAProxyConf Announcing HAProxy Fusion 2.0
June 2026 – CVE-2026-55204: null pointer dereference in H...
HAProxy Technologies · 2026-06-26 · via HAProxy Technologies

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.

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):

Support

If you are an HAProxy customer with questions about this advisory or about upgrading to the latest version, please contact our support team.

Subscribe to our blog. Get the latest release updates, tutorials, and deep-dives from HAProxy experts.