How the HTTP/2 Bomb Attack Exploits HPACK to Exhaust Server Memory

Photo of author

CyberSecureFox Editorial Team

Published:

Researchers from the company Calif have published a description of a new remote denial-of-service attack technique dubbed HTTP/2 Bomb. According to the researchers, vulnerable default HTTP/2 behavior is present on NGINX, Apache HTTPD, Microsoft IIS, Envoy and Cloudflare Pingora servers. The technique combines two known approaches — a compression bomb and Slowloris-style connection holding — to exhaust the server’s RAM. Patches are currently available only for NGINX and Apache HTTPD; fixes for the other products were not available at the time of publication. Administrators of servers with HTTP/2 enabled are advised to immediately assess their exposure and apply mitigation measures.

Attack mechanism

The attack targets HPACK, the header compression algorithm in HTTP/2, which uses Huffman coding and, according to Cloudflare, reduces header size by an average of 30%. HPACK was designed as a replacement for generic header compression that is resilient to CRIME-class attacks.

The key difference between HTTP/2 Bomb and the classic HPACK Bomb (CVE-2016-6581, disclosed in 2016) lies in the amplification source. The classic variant stored a large value in the HPACK table and referenced it repeatedly, which led to defensive limits on the total size of decoded headers. The new variant works differently: the headers are almost empty, and amplification is achieved through the internal data structures that the server allocates for each entry in the table. The limit on the size of decoded data is not triggered because there is effectively nothing to decode.

The second component of the attack is connection holding. The attacker sets a zero flow-control window, which prevents the server from freeing the allocated memory. This technique is similar to the Slowloris attack, which keeps many HTTP connections open, exhausting server resources at the application layer.

The researchers also point to links with several previously known vulnerabilities in HTTP/2 implementations: CVE-2016-8740 (DoS via specially crafted CONTINUATION frames in Apache HTTP Server) and CVE-2016-1546 (exhaustion of worker threads in an Apache HTTP/2 connection).

Impact assessment

According to Calif — whose statements should be treated with caution as single-source data without independent confirmation — a single client with a 100 Mbps connection can render a vulnerable server unavailable within seconds. It is also claimed that a single client can seize and hold up to 32 GB of server memory on Apache HTTPD and Envoy in roughly 20 seconds.

As the researchers emphasize, the fundamental problem is that the HTTP/2 specification assesses memory risk solely through the amplification factor, whereas the critical factor is the retention time of the allocated memory. A 70:1 ratio is harmless if the memory is freed when the request completes, but it becomes an attack vector when the protocol allows the client to keep the connection open at virtually no cost.

Potentially affected are all organizations using the listed web servers with HTTP/2 enabled in the default configuration. The highest risk is to publicly accessible servers that handle direct HTTP/2 connections from clients. It is important to note: no active exploitation in real-world attacks has been observed so far, and none of the related CVEs has been added to the CISA KEV catalog. The current status of the threat is the existence of a public PoC description.

Mitigation recommendations

The available protective measures vary depending on the server software in use:

  • Apache HTTPD — update the mod_http2 module to v2.0.41, which contains the fix. If updating is not possible, disable HTTP/2 by setting the Protocols http/1.1 directive.
  • NGINX — according to the researchers, a fix is available in version 1.29.8+, which adds the max_headers directive with a default value of 1000. If updating is not possible, it is recommended to disable HTTP/2 using the http2 off; directive. It should be noted that this NGINX version information comes from a single source and has not been confirmed by an official NGINX advisory.
  • Microsoft IIS, Envoy, Cloudflare Pingora — at the time the research was published, no patches were available. For these products, the only available measure is to disable HTTP/2 where feasible for the infrastructure, or to limit the number of concurrent HTTP/2 connections at the load balancer or WAF level.

Additionally, it is recommended to:

  • Audit web server configurations to determine whether HTTP/2 is enabled by default.
  • Configure monitoring for abnormal memory consumption by web server processes.
  • Limit the maximum number of concurrent HTTP/2 connections from a single IP address.
  • Monitor for official security advisories from the vendors of affected products.

Organizations running Apache HTTPD and NGINX with HTTP/2 should prioritize applying the available updates — mod_http2 v2.0.41 for Apache and version 1.29.8+ for NGINX. For Microsoft IIS, Envoy and Cloudflare Pingora servers, it is necessary to evaluate the feasibility of temporarily disabling HTTP/2 or implementing compensating controls at the network infrastructure level until official patches are released. Given that the technique exploits default behavior and does not require authentication, delaying mitigation creates a real risk to the availability of public services.


CyberSecureFox Editorial Team

The CyberSecureFox Editorial Team covers cybersecurity news, vulnerabilities, malware campaigns, ransomware activity, AI security, cloud security, and vendor security advisories. Articles are prepared using official advisories, CVE/NVD data, CISA alerts, vendor publications, and public research reports. Content is reviewed before publication and updated when new information becomes available.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.