Critical HTTP/2 Vulnerability Impacts Nginx, Apache, IIS, Envoy, Cloudflare Pingora

Key Takeaways

• A critical remote denial-of-service vulnerability, dubbed “HTTP/2 Bomb,” has been discovered affecting major web servers.
• The flaw exploits HTTP/2’s default configurations in Nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora.
• Attackers can exhaust tens of gigabytes of server memory rapidly using minimal resources, leading to service disruption.
• Patches are available for Apache httpd and Nginx; mitigation strategies are recommended for other affected servers.

A new remote denial-of-service (DoS) exploit, termed “HTTP/2 Bomb,” has come to light, targeting the default HTTP/2 settings of several of the world’s most widely deployed web servers. This vulnerability poses a significant threat to infrastructure running Nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora. A single attacker, even with a standard internet connection, can quickly consume substantial server memory, leading to system instability or complete service failure.

The exploit was identified by researcher Quang Luong, leveraging Codex, through a novel combination of two previously known security concepts: an HPACK compression bomb and a Slowloris-style connection hold. While these individual techniques have been recognized for nearly a decade, their specific chaining and the unique amplification mechanism in this new variant make it particularly potent.

Understanding the HTTP/2 Bomb Exploit

The attack combines two distinct components to achieve its devastating effect. The first involves HPACK (RFC 7541), HTTP/2’s stateful header compression scheme. HPACK works by having each communication peer maintain a dynamic table of recently encountered headers, allowing a sender to reference a previously transmitted header with a single-byte index. However, the receiving server must reconstruct a full copy of that header for each reference.

According to Jun Rong and Duc Phan, the exploit initiates by seeding the server’s dynamic table with a single header. Subsequently, the attacker sends thousands of one-byte indexed references within a single request. This forces the server to allocate significant memory for each reference—ranging from approximately 70 bytes for Nginx, IIS, and Pingora, to about 4,000 bytes for Apache httpd and Envoy—while costing the attacker only one byte of wire data per reference.

The second component of the attack exploits HTTP/2’s per-stream flow control (RFC 9113). The client advertises a zero-byte flow-control window, effectively preventing the server from completing its response. The attacker then sends a continuous trickle of one-byte WINDOW_UPDATE frames. This action perpetually resets the server’s send timeout, ensuring that every memory allocation remains pinned in place for an extended duration, transforming a transient amplification into a persistent memory drain.

The impact of this exploit is severe, as demonstrated by tests:

A Shodan analysis revealed over 880,000 public-facing websites supporting HTTP/2 and running one of the affected servers. Researcher Quang Luong noted that many of these are protected by Content Delivery Networks (CDNs), which may mitigate direct exposure to the exploit, as detailed in his blog post “Codex discovered a hidden HTTP/2 Bomb.”

For servers that limit header-field count rather than decoded size, such as Apache and Envoy, the exploit employs a Cookie header bypass. RFC 9113 §8.2.3 explicitly allows splitting a Cookie header into multiple fields, one per “crumb.” Neither Apache nor Envoy was correctly counting these crumbs against header field limits. Envoy appends each crumb into a buffer, leading to a logical ~3,600:1 amplification ratio for a 4 KB cookie value referenced 32,768 times, with measured RSS ratios reaching ~5,700:1. Apache httpd, by contrast, rebuilds the entire merged cookie string with each crumb, leaving older copies active until stream cleanup, resulting in a ~4,000:1 amplification even with an empty cookie.

The Apache httpd variant was assigned CVE-2026-49975 after responsible disclosure on May 27, 2026, with a fix committed on the same day by Stefan Eissing. Nginx addressed the vulnerability in version 1.29.8, introducing the max_headers directive with a default limit of 1,000 headers. This vulnerability class builds upon prior related CVEs, including CVE-2016-6581 (the original HPACK Bomb), CVE-2025-53020 (Apache httpd ~4,000:1 amplification), CVE-2016-8740, and CVE-2016-1546.

The research team concluded that the vulnerability stems from a specification defect in RFC 7541. Section 7.3 of the RFC frames memory risk solely as an amplification ratio and considers SETTINGS_HEADER_TABLE_SIZE as a sufficient boundary. However, it fails to account for per-entry bookkeeping overhead, which is the source of amplification in this exploit, bypassing existing decoded-size limits. This oversight was uniformly present across five independent implementations.

Proof-of-concept scripts, Docker laboratories, and detailed per-server write-ups are available on the Codex GitHub repository. Quang Luong is scheduled to present these techniques at the Real World AI Security conference at Stanford in June 2026.

What You Should Do

• Nginx: Upgrade to version 1.29.8 or newer. If an upgrade is not immediately feasible, disable HTTP/2 by setting http2 off; in your configuration.
• Apache httpd: Apply mod_http2 v2.0.41 from the standalone releases. Alternatively, disable HTTP/2 by configuring Protocols http/1.1.
• Microsoft IIS / Envoy / Cloudflare Pingora: As no direct patches are available at the time of writing, consider disabling HTTP/2 or deploying a front-end proxy that enforces a strict per-request header count limit.
• All servers: Implement memory caps per worker process using tools like cgroups, ulimit -v, or container limits. An Out-of-Memory (OOM) killed worker that respawns is a more favorable failure mode than an entire machine being pushed into swap.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.