The Attack
Researchers from the University of California discovered a novel DoS technique they have named HTTP/2 Bomb. The research was conducted using OpenAI's Codex agent to explore attack surface in HTTP/2 implementations. The finding is significant because it does not require a botnet, distributed infrastructure, or substantial bandwidth. A single machine on a standard 100 Mbps connection can exhaust tens of gigabytes of server RAM in under 20 seconds.
The attack targets default configurations of the most widely deployed web servers on the internet: NGINX, Apache HTTP Server, Microsoft IIS, Envoy, and Cloudflare Pingora. These five servers collectively handle the vast majority of HTTP traffic on the public internet. A vulnerability that affects all of them simultaneously is, by definition, a vulnerability that affects most of the web.
In testing, the researchers demonstrated that Envoy could be forced to exhaust 32 GB of RAM in approximately 10 seconds. Apache httpd reached the same threshold in roughly 18 seconds. Both results were achieved from a single client connection. No amplification reflectors. No spoofed traffic. No botnet coordination. One machine, one connection, one server down.
How It Works
The HTTP/2 Bomb combines two techniques that are individually well-understood but have not previously been weaponized together in this way: HPACK compression amplification and flow control stalling.
HPACK Compression Amplification
HTTP/2 uses HPACK compression to reduce the size of headers transmitted between client and server. HPACK maintains a dynamic table of previously seen header values. When a header value has been seen before, the client can reference it by index rather than retransmitting the full value. The server then decompresses the reference back to the original value in memory.
The attack exploits this by sending a large number of requests with tiny, highly compressed header references that decompress into substantially larger values in server memory. The on-the-wire cost is minimal: a few bytes per header reference. The server-side cost is significant: each reference expands into the full header value that was originally stored in the dynamic table. The compression ratio works against the server, turning a small amount of inbound bandwidth into a large amount of memory allocation.
Flow Control Stalling
HTTP/2 includes a flow control mechanism that allows either side of a connection to signal how much data it is willing to receive. The client can advertise a very small receive window, effectively telling the server "I can only accept a few bytes right now." The server is then obligated to hold response data in memory until the client opens its window to accept more.
The attack leverages this by never opening the flow control window. The client sends requests that trigger server responses, but refuses to acknowledge the response data. The server allocates memory to buffer the responses, waiting for the client to indicate readiness to receive. The client never does. The memory is held indefinitely, or until the server runs out of it.
The Combination
The HTTP/2 Bomb combines both techniques on a single connection. The client sends a flood of requests with tiny compressed headers (minimizing inbound bandwidth) that generate large responses on the server side. Simultaneously, the client stalls the flow control window, preventing the server from flushing those responses. The server allocates memory for both the decompressed headers and the buffered responses. Memory consumption grows rapidly with each request while the client's bandwidth usage remains negligible.
This is what makes the attack so efficient. Traditional volumetric DoS requires the attacker to generate traffic volume comparable to the damage they inflict. The HTTP/2 Bomb inverts this ratio. The attacker sends kilobytes. The server allocates gigabytes. The asymmetry is extreme.
Affected Servers and Patch Status
The attack affects default configurations of five major web server platforms. Patch status varies:
- NGINX: Patch available. Administrators should update to the latest version and review HTTP/2 connection settings.
- Apache HTTP Server (httpd): Patch available. The fix limits memory allocation per connection for HTTP/2 streams.
- Microsoft IIS: Still vulnerable at time of writing. No patch has been released.
- Envoy: Still vulnerable at time of writing. Given that Envoy was the fastest to exhaust memory in testing (10 seconds to 32 GB), this is particularly concerning for service mesh deployments that use Envoy as a sidecar proxy.
- Cloudflare Pingora: Still vulnerable at time of writing. Pingora is used internally by Cloudflare and is also available as an open-source project for building custom proxies.
The partial patch coverage creates an awkward situation. Organizations running NGINX or Apache can update. Organizations running IIS, Envoy, or Pingora-based infrastructure need to implement workarounds until patches are available.
Mitigation Strategies
For servers where patches are available, apply them. For those still waiting on patches, several mitigation strategies reduce exposure:
Disable HTTP/2. The most direct mitigation is to disable HTTP/2 and fall back to HTTP/1.1. This eliminates the attack surface entirely, since the technique depends on HPACK and HTTP/2 flow control. The cost is a modest performance regression: HTTP/1.1 lacks header compression and multiplexing, which means more connections and slightly higher latency for clients. For many workloads, this tradeoff is acceptable until patches land.
Implement a reverse proxy with strict limits. Place a reverse proxy in front of vulnerable servers that enforces strict limits on HTTP/2 header count, header size, and concurrent streams per connection. If the proxy itself is not vulnerable (or is patched), it absorbs the attack before it reaches the backend. This is the standard approach for environments that cannot disable HTTP/2.
Limit concurrent streams and header table size. Most HTTP/2 implementations expose configuration parameters for SETTINGS_MAX_CONCURRENT_STREAMS, SETTINGS_HEADER_TABLE_SIZE, and SETTINGS_MAX_HEADER_LIST_SIZE. Reducing these values from their defaults limits how much memory a single connection can allocate. The specific values depend on the server and workload, but reducing SETTINGS_HEADER_TABLE_SIZE from the default 4096 bytes to a smaller value directly limits the HPACK amplification potential.
Monitor per-connection memory usage. Even without a specific defense against HTTP/2 Bomb, monitoring memory consumption per connection or per client IP allows early detection. A single connection consuming hundreds of megabytes or gigabytes of RAM is anomalous in virtually every workload. Alerting on this pattern enables manual intervention before the server is fully exhausted.
Context: The HTTP/2 Attack Surface
HTTP/2 Bomb joins a growing list of attacks that exploit the complexity of the HTTP/2 protocol. The protocol was designed for performance: multiplexing, header compression, server push, and stream prioritization all reduce latency and improve throughput for legitimate use. But each of these features introduces state that the server must maintain per connection, and that state is attackable.
In 2023, HTTP/2 Rapid Reset (CVE-2023-44487) demonstrated that sending and immediately canceling HTTP/2 streams could overwhelm servers. The attack created new streams faster than the server could process the cancellations, exhausting CPU and memory. It was used in attacks that exceeded 398 million requests per second, the largest Layer 7 DDoS attacks ever recorded at that time. Google, Cloudflare, and AWS all published advisories and patches.
In 2019, Netflix researchers disclosed a set of HTTP/2 implementation vulnerabilities including Ping Flood, Settings Flood, and Reset Flood attacks. Each exploited different aspects of HTTP/2 frame processing to consume server resources. Patches were released for NGINX, Apache, H2O, and other implementations.
HTTP/2 Bomb represents the next iteration. Where Rapid Reset attacked the stream lifecycle, HTTP/2 Bomb attacks the compression and flow control subsystems. The pattern is consistent: every stateful feature in HTTP/2 is a potential resource exhaustion vector. As researchers continue to probe the protocol, additional techniques are likely to emerge.
This pattern has implications for HTTP/3 and QUIC adoption. HTTP/3 uses QPACK instead of HPACK for header compression and implements its own flow control at the transport layer. While the specific HTTP/2 Bomb technique does not translate directly to HTTP/3, the general principle of exploiting compression and flow control asymmetry applies to any protocol that implements these features. HTTP/3 implementations should be proactively tested for analogous vulnerabilities before they become the dominant protocol on the web.
Detection Considerations
The HTTP/2 Bomb is challenging to detect with traditional network monitoring because the inbound traffic volume is small. Volumetric detection systems that trigger on packets per second or bits per second will not flag the attack, because the attacker is sending very little traffic. The damage is happening in server memory, not on the wire.
Effective detection requires monitoring the server side: memory consumption, per-connection resource allocation, and HTTP/2 stream metrics. A connection that opens many streams with tiny headers, receives large responses, but never advances its flow control window, is the signature. Web server access logs alone will not capture this pattern because the attack operates below the request logging layer, at the HTTP/2 frame level.
For organizations using Flowtriq, the agent's per-second traffic monitoring provides the network-level component. A server suddenly receiving sustained connections from a small number of sources while its resource utilization spikes dramatically is a detectable anomaly even if the inbound traffic volume appears normal. The combination of network-level anomaly detection and server-side resource monitoring provides the most complete detection picture for this class of attack.
The Takeaway
The HTTP/2 Bomb is a reminder that protocol complexity is attack surface. HTTP/2 was adopted because it improved performance for legitimate use. The same features that make it fast, header compression and flow control, are now being weaponized to make it dangerous. Every server operator running HTTP/2 in its default configuration should evaluate their exposure and either patch (where available) or implement mitigations (where not).
The fact that three of the five affected implementations remain unpatched means this is an active, exploitable technique. It does not require significant resources or sophistication. A single attacker with a single machine can take down a production server. The window between disclosure and universal patching is when attacks happen. If you run IIS, Envoy, or Pingora, the time to implement workarounds is now.
Low-bandwidth attacks are still attacks. The HTTP/2 Bomb sends kilobytes to consume gigabytes. Flowtriq's per-second analysis detects anomalous connection patterns and resource exhaustion signals that volumetric-only tools miss. $9.99/node/month with a free 7-day trial. Start your trial or explore the feature set.