Executive summary (TL;DR)
At a glance
The issue: A critical resource-exhaustion vulnerability known as the "HTTP/2 Bomb" affects multiple major web servers, including NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora (CVE-2026-49975).
Severity: Critical. A single home computer on a 100 Mbps connection can knock a vulnerable server offline in seconds.
Status: Proof-of-concept (PoC) code is available, and technical details are public.
HAProxy protection:
HAProxy Enterprise / Community: HAProxy is architecturally safe from being overwhelmed by this exploit due to its strict memory constraints.
Configuration: An optional configuration update can be applied immediately to drop malicious clients at the network edge and conserve CPU cycles.
What is CVE-2026-49975?
On June 2, 2026, security researchers disclosed a remote denial-of-service (DoS) exploit named the HTTP/2 Bomb. This flaw allows unauthenticated remote attackers to rapidly exhaust server memory, rendering major web servers inaccessible.
Technical impact
The vulnerability stems from an attack chain that combines two older techniques: a compression bomb and a Slowloris-style hold.
Compression bomb: The attack targets HPACK, the HTTP/2 header compression scheme. The attacker seeds the server's dynamic table with a nearly empty header and emits thousands of 1-byte indexed references to it. Because the header is tiny, standard decoded-size limits never fire.
However, each 1-byte reference forces the server to create a fresh per-entry bookkeeping allocation, causing massive memory amplification (up to 5,700:1). For servers that cap field counts, attackers bypass limits by splitting the Cookie header into individual crumbs, which Apache and Envoy fail to count properly.Slowloris hold: The attacker advertises a zero-byte flow-control window. This action blocks the server from finishing its response, while the attacker drips 1-byte WINDOW_UPDATE frames to reset send timeouts.
This combination pins allocations in memory indefinitely. A single client can consume and hold 32 GB of server memory in less than 20 seconds, pushing backend machines into swap and killing system performance.
If you are using HAProxy in front of your servers, then you are already protected.
Affected versions
Default configurations of NGINX (before 1.29.8)
Apache HTTPD (before mod_http2 v2.0.41)
Microsoft IIS (Windows Server 2025
Envoy (1.37.2 and older
Cloudflare Pingora
Defending your infrastructure: Virtual patching vs. host reconfiguration
If your web servers are exposed directly to the internet without a security proxy in front of them, you must immediately configure manual host limits or rush out vendor updates to completely remove the threat:
Option A: Manual server reconfiguration
Patch the source: Apply the official vendor patches to your backend web servers as soon as possible.
NGINX: Upgrade to version 1.29.8 or later to use the new max_headers directive.
Apache HTTPD: Upgrade mod_http2 to version v2.0.41 or later.
Disable HTTP/2 on un-patched servers: If patches are unavailable (such as for IIS, Envoy, or Pingora), disable HTTP/2 on those specific servers to avoid exposure.
Cap host worker memory: Configure cgroups, container limits, or ulimit -v tight enough on your web servers so that a bombed worker gets OOM-killed and respawned clean before it drags the host machine into a memory-swap loop.
Option B: “Virtual patching” with HAProxy
If you deploy HAProxy or HAProxy Enterprise in front of your web servers, none of the intrusive backend modifications above are required. Because HAProxy acts as an isolated protocol terminator at the edge of your network, it safely handles client-side HTTP/2 processing within its own tightly budgeted, fixed-size memory boundaries.
It then passes sanitized (un-bombable) traffic down to your internal infrastructure. Even if your underlying web applications remain un-patched or vulnerable, they are immediately 100% protected. HAProxy acts as an instant virtual patch that removes the administrative rush to reconfigure your core server fleet.
How HAProxy protects your infrastructure
While patching upstream web servers is the ultimate remediation, HAProxy sits at the edge of your network, providing a critical first line of defense. You can stop the attack before it ever reaches your vulnerable servers.
Unlike most load balancers and reverse proxies that struggle with multiplexed streams because they rely on dynamic memory tracking, HAProxy stands out. HAProxy treats HTTP/2 streams with strict memory constraints and processes frames at bare-metal speeds.
Automatic protection with HAProxy
HAProxy is architecturally safe from being overwhelmed by the HTTP/2 Bomb exploit. Its core design limits the memory footprint of individual connections and streams, preventing an attacker from triggering out-of-memory (OOM) conditions or massive memory inflation that hits other servers. HAProxy stays stable even under high-intensity resource-exhaustion attempts.
You don't need to change anything for HAProxy itself to survive this attack
Optional: Immediate mitigation configuration
Even though HAProxy will not crash, you can use its configuration layer to actively reject attacking clients rather than spend CPU cycles processing malformed frames. In fact, it will actually “reverse” the attack by causing the malicious client to use twice as much memory and 100 times as much CPU as HAProxy!
Using HAProxy stick tables, you can track anomalous protocol behavior, including rapid resets and malformed continuation frames, and reject malicious connections before they reach application backends.
Add the following configuration snippet to your frontend to conserve resources and frustrate the attacker:
| global | |
| # 1. HTTP/2 Rapid Reset & Burst Throttling (Requires HAProxy 3.4+) | |
| # Client Punishment: Processes exactly one stream reset per execution loop. | |
| # This serializes multiplexed floods, making volumetric reset attacks unnoticeable. | |
| tune.h2.fe.max-rst-at-once 1 | |
| # 2. Global Protocol Fuzz Ceiling | |
| # Automated safety switch: Globally terminates connections that exceed 200 transport glitches | |
| tune.h2.fe.glitches-threshold 200 | |
| frontend https_in | |
| bind *:443 ssl crt /etc/haproxy/certs/my_site.pem alpn h2,http/1.1 | |
| mode http | |
| # Security Stick-Table | |
| # A single unified table tracking client burst rates and protocol anomalies simultaneously | |
| stick-table type ip size 1m expire 5m store http_req_rate(10s),glitch_cnt | |
| # EARLY DROP LAYER: Track and evaluate clients at the raw network layer. | |
| # This catches abusive clients BEFORE they can waste CPU cycles on TLS handshakes. | |
| # Initialize tracking slot 'sc0' for the incoming source IP | |
| tcp-request connection track-sc0 src | |
| # Defensive Action A: Catch Persistent Protocol Glitchers / Window Stalls | |
| # Instantly drop the raw socket if an IP accumulates more than 1000 cumulative glitches. | |
| tcp-request connection reject if { sc0_glitch_cnt gt 1000 } | |
| # Defensive Action B: Catch Volumetric Request Floods | |
| # Instantly drop the raw socket if a client exceeds clean request burst limits. | |
| tcp-request connection reject if { sc0_http_req_rate gt 200 } | |
| default_backend web_servers |
Note: Test configuration changes in staging before applying to production. The thresholds above are reasonable starting points but may need tuning depending on your traffic patterns.
Conclusion
Vulnerabilities like CVE-2026-49975 highlight the volatility of the modern threat landscape and show that relying solely on patching backend applications leaves a dangerous window of exposure. HAProxy provides the robust, high-performance security needed to virtually patch vulnerabilities instantly at the edge of your network.
Next steps:
Community users: Apply the optional mitigation configuration above to reject abusive traffic early and reduce unnecessary CPU load. This will also reject other types of similar attacks.
Evaluate your security: If you want comprehensive threat protection and automated zero-day defense, start a free trial of HAProxy Enterprise load balancer today.
