HTTP / 2 Bomb: The vulnerability that can empty the RAM from your servers in seconds

A new method of denial of service baptized by its discoverers as HTTP / 2 Bomb shows that the combination of already known techniques can become vulnerable to modern servers in a matter of seconds: HPACK (HTTP / 2 header compression) is used to amplify memory use and HTTP / 2 flow control is manipulated to indefinitely retain that assigned memory.

According to the technical report published by Calif researchers, and available on their blog, a single domestic machine with a 100 Mbps connection can force servers such as Envoy, Apache httpd, NGINX or IIS to consume tens of gigabytes of RAM in seconds; the experiments played by the team show extreme amplification ratios - up to 5,700 bytes consumed by each byte sent in the case of Envoy - and drains of 32-64 GB in less than a minute in default configurations. More details and context of the discovery are in Calif's statement: https: / / blog.calif.io / p / codex-discovered-a-hidden-http2-bomb.

The first "leg" of the attack exploits how HPACK maintains a dynamic table of header inputs: the attacker inserts a small input and the reference repeatedly using its indexed representation of a byte, making a minimum amount of network data cause a lot of internal memory by accounting and structures that the server reserves for each header. The second "paw" takes advantage of the HTTP / 2 flow control mechanism: the client announces a zero byte window and prevents the response from being completed, while the server sends small WINDOW _ UPDATE bursts or maintains the connection status to avoid waiting time; the result is that the reserved memory is not released.

This approach evades traditional measures that limit the total size of decoded headers because the headers used on the holding are intentionally small; amplification occurs in internal management per header and in structures related to the flow state. The HPACK specification recognizes memory amplification risks, but researchers point out that it does not adequately address the effect combined with indefinite retention via flow control: the interaction between subsystems is what causes the catastrophic impact.

Calif already published concept tests in GitHub, so operators and security equipment must act with caution and haste: https: / / github.com / califio / publications / tree / main / MADBugs / http2-bomb. It is also recommended to review the HPACK specification to understand the root of the technical problem: https: / / httpwg.org / specs / rfc7541.html.

Some suppliers and projects have already launched mitigation: NGINX introduced the directive max _ headers in version 1.29.8 and Apache corrected mod _ http2 in the version indicated by the team; however, at the date of this report there were no official patches for all the implementations concerned, including certain versions of Envoy, Microsoft IIS or the Cloudflare Pingora engine. Where no patch is available, pragmatic recommendations are to disable HTTP / 2 if feasible, or to place an inverse / CDN proxy that filters and limits the number of headers and flow controls before they reach the home server.

For operations and incident response teams, the specific actions that should be prioritized include applying available patches immediately, reviewing the exposure of HTTP / 2 endpoints in public infrastructure, enabling strict connection limits (maximum number of simultaneous headers and streams), and ensuring that proxies or WAFs apply hard thresholds. In addition, setting resource limits by process / worker and kernel rules (OOM-killer and cgroups) helps contain the damage when the memory starts to grow.

In terms of detection, early indicators are unusual patterns of "half-open" or with persistent zero-flow windows, a rapid increase in memory use by HTTP / 2 processes, and a high number of repeated inputs in decoded header meters. Monitoring connection metrics, response times and internal meters of the HTTP / 2 module of each server makes it easier to identify operating attempts before the machine becomes unusable.

This finding also has a community-relevant dimension: it was discovered with the help of a co-ordinated software agent (Codex) by human researchers, which highlights how IA tools can accelerate the identification of complex vectors but also how their use requires responsible disclosure standards. The full technical presentation will be made public at the Real World AI Security conference; in the meantime, the existence of PoC requires action as if the risk was real and exploitable.

If your service serves public traffic, prioritize a quick inventory of which components expose HTTP / 2, update NGINX / Apache when appropriate and, if you cannot park immediately, place a CDN / proxy that will validate and limit header counts per connection. Document the mitigation measures and tests in your incident playbook: the speed of detection and the application of connection limits are the difference between a minor incident and a complete drop in service.

Finally, the nature of the problem recalls that the security of modern protocols depends not only on individual specifications but on their interactions in real implementations; the infrastructure-responsible teams must incorporate HTTP / 2-specific stress tests into their security and defensive architecture validations.