HTTP/2 Bomb (CVE-2026-49975): The Industry-Wide Web Server DoS Vulnerability and Why LiteSpeed Customers Are Not Affected

On June 2, 2026, the cybersecurity firm Calif publicly disclosed CVE-2026-49975, a remote denial-of-service vulnerability they named HTTP/2 Bomb. The vulnerability affects the default HTTP/2 configurations of NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora — collectively, the web servers that power most of the public internet. A single attacker on an ordinary home internet connection (100 Mbps) can consume roughly 32 GB of server memory in 20 seconds, rendering a web server unreachable until it is restarted. Approximately 880,000 websites that support HTTP/2 with default configurations on the affected servers are potentially exposed.

Notably absent from the affected list: LiteSpeed Web Server, OpenLiteSpeed, and LiteSpeed Web ADC. LiteSpeed Technologies confirmed on June 5 that their server products are not vulnerable to HTTP/2 Bomb because LiteSpeed shares no code with Apache despite being a drop-in replacement for it. Existing Gotekky customers on legacy shared and reseller environments run on LiteSpeed and were therefore structurally protected. Other existing and managed server environments vary according to the deployed web server and must be assessed by their actual Apache, NGINX or LiteSpeed configuration.

The rest of this guide explains what HTTP/2 Bomb is technically, why LiteSpeed's architecture avoids it, what Cloudflare's protection adds for customers on Cloudflare-fronted sites, and what operators of NGINX, Apache, IIS, Envoy, or Pingora-based servers need to do urgently.

What HTTP/2 Bomb actually is

HTTP/2 Bomb is not a single new vulnerability. It is the combination of two known denial-of-service techniques that have been publicly documented for nearly a decade but were not previously known to compose against modern web servers. The combination was discovered by OpenAI's Codex agent reading the codebases of affected servers and recognizing that the two techniques compose. The discovery is credited to Quang Luong of Calif, with Jun Rong and Duc Phan validating the attack against additional server platforms.

The two halves of the attack:

• HPACK Bomb (originally CVE-2016-6581, by Cory Benfield): HPACK is HTTP/2's header compression scheme. By design, one byte on the wire can become one full header allocation on the server. An attacker sends specially crafted compressed headers where each byte expands into a full header entry. A few hundred bytes of network traffic can trigger thousands of header allocations on the server, consuming megabytes of memory per request.
• Slowloris-style flow-control hold: HTTP/2 has a per-stream flow-control window that the receiver can open or close. An attacker keeps the server's flow-control window at zero, meaning the server cannot send response data and therefore cannot free the memory associated with the request. The request stays open indefinitely. Memory accumulates and is never released.

Combined: the attacker opens many HTTP/2 streams, each carrying an HPACK compression bomb that allocates thousands of header entries on the server. The attacker holds the flow-control window at zero on each stream, preventing the server from completing or freeing any of them. Memory consumption grows linearly with the number of open streams times the size of each HPACK bomb, and a 100 Mbps connection can sustain enough concurrent attack streams to exhaust 32 GB of memory in 20 seconds.

The clever part of the attack is what each half costs the attacker. HPACK Bomb alone is trivially blocked by header count limits (which most servers enforce by default). Slowloris alone is trivially blocked by connection or request timeouts. The combination defeats both defenses because each half hides inside the legitimate-looking behavior of the other: the HPACK bomb stays under per-stream header limits because thousands of streams are used in parallel, and the Slowloris hold looks like normal flow control that the server is obligated to honor.

Why LiteSpeed is not vulnerable

The HTTP/2 Bomb vulnerability lives in the default HTTP/2 implementations of NGINX, Apache HTTPD's mod_http2, Microsoft IIS, Envoy, and Cloudflare Pingora. These five products share the property that their HPACK decoder allocates per-header memory eagerly and that their flow-control implementation does not bound the total memory held by streams in a stalled state.

LiteSpeed Web Server is an Apache drop-in replacement, meaning it accepts the same configuration syntax and serves the same workloads, but it shares no source code with Apache. LiteSpeed's HTTP/2 implementation is independently written and does not exhibit the same combination of eager HPACK allocation plus unbounded flow-control memory retention. The same independent codebase property holds for OpenLiteSpeed (the open-source variant) and LiteSpeed Web ADC (the application delivery controller).

LiteSpeed Technologies confirmed on June 5, 2026 that their server products are effectively not vulnerable to HTTP/2 Bomb attacks. The "effectively" qualifier reflects engineering caution: the company committed to additional review of edge cases, but no exploitation path against LiteSpeed has been demonstrated, and the architectural reasons LiteSpeed avoids the vulnerability are structural rather than incidental.

This is the second time in recent years that LiteSpeed customers have been incidentally protected from an industry-wide vulnerability because of architectural independence from Apache. The pattern reflects a broader truth about web server diversity: when most of the internet runs the same handful of HTTP server codebases, a vulnerability in one of those codebases has very high blast radius. Using a less-common server with an independent codebase is a form of defense in depth that does not show up in patch logs but pays off when industry-wide events like HTTP/2 Bomb arrive.

Cloudflare adds a second protection layer

For sites that sit behind Cloudflare's edge (which includes a significant portion of Gotekky-hosted customer sites), Cloudflare confirmed on June 3, 2026 that their existing architecture and DDoS mitigation systems automatically detect and mitigate HTTP/2 Bomb attacks. Cloudflare's edge servers terminate the HTTP/2 connection before it reaches the origin, so even if an origin server were vulnerable, the attack pattern would be blocked at Cloudflare's edge rather than reaching the backend.

This matters for two reasons. First, Cloudflare-fronted sites get protection regardless of what origin web server they run. A customer on a Cloudflare-fronted hosting setup with NGINX, Apache, IIS, or any other affected origin server is still protected because Cloudflare's edge filters the attack. Second, it means Gotekky customers on Cloudflare-fronted sites benefit from two independent layers of protection: LiteSpeed's structural immunity at the origin, and Cloudflare's mitigation at the edge. Either layer alone is sufficient. Both together is conservative defense in depth.

What Gotekky customers need to know by deployed web server

The relevant distinction is the software actually terminating HTTP/2, not the commercial name of the hosting plan:

• Legacy shared and reseller environments using LiteSpeed: structurally not vulnerable according to the advisory. No action was required for this specific issue.
• Managed environments using LiteSpeed: structurally not vulnerable according to the advisory.
• Managed environments using Apache or NGINX: required review and the applicable patched version or mitigation.
• Self-managed environments: the operator was responsible for identifying the web server and applying the vendor guidance.

If you are not sure which web server an environment is running, check from the command line as root:

# Is LiteSpeed running?
ls /usr/local/lsws/bin/lshttpd 2>/dev/null && echo "LiteSpeed installed"
ps aux | grep -E "(lshttpd|litespeed)" | grep -v grep | head -3

# Or check what is listening on port 443
ss -tlnp | grep -E ':80|:443'

If lshttpd appears, the environment is using LiteSpeed. If you see httpd, apache2 or nginx, follow the affected-server guidance below and verify the installed version and configuration.

For supported Gotekky managed environments, patching and mitigation are handled according to the documented management scope. Operators of self-managed environments must apply the vendor guidance themselves.

Cloudflare-fronted sites get a second protection layer regardless of origin web server. If your site sits behind Cloudflare and your origin runs Apache or NGINX without the patch yet, Cloudflare's edge mitigation still blocks the attack from reaching the origin. This is not a substitute for patching the origin because Cloudflare can be bypassed if the origin IP is discoverable, but it is meaningful interim protection.

If you operate NGINX, Apache, IIS, Envoy, or Pingora servers, do this today

The patch and mitigation status varies by server. As of June 9, 2026:

NGINX

Fixed in NGINX 1.29.8, released in April 2026. The fix adds a new max_headers directive that defaults to 1000 and caps the number of headers a single request can declare. Upgrade with your distribution's package manager. If you cannot upgrade immediately, disable HTTP/2 in your NGINX configuration:

server {
    listen 443 ssl;
    # remove or comment out:
    # http2 on;
}

Disabling HTTP/2 has performance implications for clients on HTTPS but eliminates the attack surface entirely. This is a viable temporary mitigation while you schedule the NGINX upgrade.

Apache HTTPD with mod_http2

Fixed in mod_http2 v2.0.41, released in late May 2026 by maintainer Stefan Eissing. The fix counts cookie header fragments against the existing LimitRequestFields directive, which prevents the HPACK bomb from inflating header allocations beyond the configured limit. The fix is available from the standalone mod_http2 releases and in Apache httpd trunk. Upgrade via your distribution's package manager or rebuild from source.

If you cannot upgrade immediately, you can disable mod_http2 in your Apache configuration to force HTTP/1.1 fallback:

LoadModule http2_module modules/mod_http2.so
# Either comment out the LoadModule line entirely,
# or remove "h2" from the Protocols directive:
Protocols h2 h2c http/1.1
# becomes:
Protocols http/1.1

Microsoft IIS

No patch available as of this writing. Microsoft has been notified by the Calif research team. For Windows hosting administrators, the recommended interim mitigations are: disable HTTP/2 in IIS configuration (Application Pool settings, advanced settings, Enable HTTP/2 set to false), place an HTTP/2-protocol-aware WAF or reverse proxy in front of IIS that enforces header-count limits, or move HTTP/2 termination to a Cloudflare-style edge.

Envoy

Initial patches released on June 3, 2026. Calif is validating the fix and may issue additional guidance if remaining gaps are identified. If you operate Envoy as part of a service mesh or API gateway deployment, upgrade to the latest patched release and watch the Calif blog for follow-up guidance.

Cloudflare Pingora

Cloudflare confirmed on June 3 that their edge DDoS mitigation handles HTTP/2 Bomb attacks against Cloudflare-protected sites automatically. No customer action is required for sites behind Cloudflare. If you operate your own Pingora deployment outside Cloudflare's edge (Cloudflare open-sourced Pingora, and some organizations run it independently), no patch is yet available and the affected-server guidance applies.

What this means for the broader hosting industry

HTTP/2 Bomb is operationally significant for two reasons that go beyond the immediate vulnerability. First, the attack was discovered by an AI assistant (OpenAI's Codex) reading the public source code of affected servers and recognizing that two independently-documented decade-old techniques compose into a novel attack. The Calif researchers note that both halves of the attack have been public for ten years, but no human had previously assembled them against these specific servers. This is now the second major web-server-class vulnerability in 2026 that was AI-discovered (following the Linux kernel Copy Fail and Dirty Frag disclosures in April and May). The pattern is established: AI-assisted code review is now genuinely effective at finding vulnerabilities that human researchers missed, and the discovery cadence for high-impact vulnerabilities is accelerating as a result.

Second, the vulnerability highlights the value of web server diversity. When 80%+ of the public web runs on a small handful of HTTP server codebases, a structural vulnerability in any one of them affects an enormous share of internet traffic. The 880,000 affected sites estimated by Calif is likely conservative because it only counts sites with detectable default configurations. The actual exposed population is larger. Operators who chose LiteSpeed (or other less-common servers with independent codebases) are protected from this specific attack by architectural luck, but they also benefit more generally from the defense-in-depth property of running a non-default stack.

For Canadian hosting providers under PIPEDA, Law 25 in Quebec, and broader regulatory frameworks, the takeaway is that monoculture risk in web-server choice is a real operational concern. Gotekky’s historical use of LiteSpeed on legacy shared and reseller platforms, and on some managed environments, predates HTTP/2 Bomb by years. The protection it provided in this incident illustrates the value of architectural diversity, while affected Apache and NGINX environments illustrate why prompt patching and documented exposure analysis remain necessary.

The complete spring 2026 hosting infrastructure security backlog now spans: the cPanel CVE-2026-41940 authentication bypass, three additional cPanel emergency security releases through May, the WHMCS CVE-2026-29204 authorization bypass, two actively-exploited LiteSpeed User-End cPanel Plugin vulnerabilities (which are separate from LiteSpeed Web Server and do affect cPanel servers running that plugin), four separate Linux kernel privilege escalation vulnerabilities, and now HTTP/2 Bomb. Gotekky maintains separate guides for each significant disclosure. The combined pattern reflects an environment in which continuous patch deployment and architectural diversity are baseline expectations rather than optional hardening.