News

Security analysts have revealed a remote denial-of-service technique that impacts several widely used web servers, including NGINX, Apache HTTPD, Microsoft IIS, Envoy and Cloudflare’s Pingora. The issue, labeled “HTTP/2 Bomb” by Calif, exists in the default HTTP/2 settings of those servers and was unearthed using OpenAI Codex by chaining two prior methods into a single, more potent exploit.

Calif explained that the exploit fuses a compression-style amplification with a Slowloris-like connection hold. It targets HPACK, the header-compression mechanism used by HTTP/2: tiny data on the wire is converted into full header allocations inside the server, and this allocation is repeated thousands of times within a single request. At the same time the attacker uses a zero-sized flow-control window to prevent the server from releasing those allocations, keeping the memory pinned indefinitely.

HPACK is the HTTP/2-specific header compression algorithm that uses Huffman coding to shrink header metadata – typically reducing header size by about 30% – and was designed to be robust against attacks such as CRIME (Compression Ratio Info-leak Made Easy), which can expose cookies and other secrets in compressed headers. Slowloris is an application-layer DoS approach that overwhelms targets by opening and maintaining a large number of slow or incomplete HTTP connections, forcing the server to tie up resources.

The new HTTP/2 Bomb builds on historical techniques. It draws inspiration from earlier HPACK Bomb variants (for example CVE-2016-6581) and other HTTP/2 memory and DoS issues disclosed previously, such as CVE-2025-53020 (a memory-exhaustion flaw in Apache httpd’s HTTP/2 implementation) and older Apache problems caused by crafted CONTINUATION frames (CVE-2016-8740) and worker-thread starvation in HTTP/2 sessions (CVE-2016-1546).

According to Calif, the innovation is not the idea of compression amplification itself but the place where the amplification happens. Classic “bomb” attacks insert a large value and reference it repeatedly so servers learned to enforce decoded-size caps. This variation flips the model: the headers themselves are almost empty, but the server creates per-entry bookkeeping metadata around each header, generating amplification from allocation overhead rather than decoded payload size. Because there is almost nothing to decode, decoded-size limits do not trigger.

The practical impact can be severe. Calif notes that a single attacker using a typical home connection (for example a 100 Mbps line) could potentially render a vulnerable server unreachable in a matter of seconds. In tests, a lone client was able to allocate and hold roughly 32 GB of server memory against Apache HTTPD and Envoy in about 20 seconds.

Mitigation guidance is already available for some platforms:

• NGINX – upgrade to 1.29.8 or newer, which introduces a max_headers directive defaulting to 1000. If updating is not possible, operators can disable HTTP/2 by adding http2 off; to their configuration.
• Apache HTTPD addressed the bug in mod_http2 v2.0.41; until an upgrade is applied, administrators can disable HTTP/2 by setting Protocols http/1.1 in their configuration.

At the time of writing, Microsoft IIS, Envoy and Cloudflare Pingora did not have public patches available.

Calif emphasized a broader protocol-design concern: the HTTP/2 specification frames memory risk mainly as an amplification ratio, but that ignores how long allocated memory can be kept. An amplifier is harmless if allocations are promptly released when a request finishes; it becomes dangerous when HTTP/2 allows clients to keep connections open cheaply and thereby pin every allocated byte for as long as they choose.

Operators running HTTP/2 endpoints should apply vendor fixes where offered, consider limiting header resources where possible, or temporarily disable HTTP/2 until patches are applied. Monitoring connection counts and memory use may also help detect attempts to exploit this new amplification vector.