Cybersecurity researchers have discovered a remote denial-of-service exploit that affects major web servers, including NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora.
The vulnerability has been codenamed HTTP/2 Bomb by Calif.
"The vulnerable behavior exists in each server's default HTTP/2 configuration," the company said, adding it was discovered by OpenAI Codex by chaining together two known techniques: a compression bomb and a Slowloris-style hold.
"The bomb targets HPACK, HTTP/2's header compression scheme: one byte on the wire becomes one full header allocation on the server, repeated thousands of times per request," Calif added. "The hold is a zero-byte flow-control window that keeps the server from ever freeing any of it."
HPACK is a dedicated header compression algorithm for HTTP/2 used for compressing request and response metadata using Huffman encoding that results in an average reduction of 30% in header size. It's also designed to be resilient to attacks like CRIME (short for "Compression Ratio Info-leak Made Easy") that can leak authentication cookies from compressed headers.
Slowloris, on the other hand, is a type of denial-of-service (DoS) attack that allows a threat actor to overwhelm a targeted server by opening and maintaining many simultaneous HTTP connections between the attacker and the target. It is an application-layer attack.
HTTP/2 Bomb is inspired by various known approaches like HPACK Bomb (aka CVE-2016-6581), which was first disclosed in 2016, as well as CVE-2025-53020, a memory exhaustion vulnerability in Apache httpd's HTTP/2 implementation, and two DoS flaws in Apache HTTP Server via crafted CONTINUATION frames (CVE-2016-8740) and worker-thread starvation (CVE-2016-1546) in an HTTP/2 connection.
"What's new here is where the amplification comes from," Calif said. "The classic bomb stuffs a large value into the table and references it repeatedly, so servers learned to cap the total decoded header size. Our variant goes the other way: the header is nearly empty, and the amplification comes from the per-entry bookkeeping the server allocates around it. The decoded-size limit never fires because there's almost nothing to decode."
In a hypothetical attack scenario, a home computer on a 100Mbps connection has the potential to render a vulnerable server inaccessible within seconds. What's more, a single client can consume and hold 32GB of server memory against Apache HTTPD and Envoy in about 20 seconds.
To counter the vulnerability, it's advised to apply the following mitigations -
- NGINX - Upgrade to 1.29.8+, which adds the max_headers directive with a default of 1000. If upgrade is not an option, it's recommended to disable HTTP/2 with http2 off;.
- Apache HTTPD - Fixed in mod_http2 v2.0.41. If upgrade is not an option, it's recommended to set Protocols http/1.1 to disable HTTP/2.
- Microsoft IIS, Envoy, and Cloudflare Pingora - No patch available as of writing.
"The deeper miss is that the spec frames memory risk purely as an amplification ratio, and ratio is only half the equation," Calif said. "A 70:1 amplifier is harmless if the memory is freed when the request completes. It becomes an attack because HTTP/2 lets the client hold the connection open almost for free, pinning every allocated byte for as long as they like."
