Yesterday, on June 3, 2026, calif_io published a blog post about a new HTTP/2 DoS technique that chains together two vulnerabilities and can be devastating for affected infrastructure:

The attack was discovered by Codex, which chained two techniques known to humans for a decade: 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. The hold is a zero-byte flow-control window that keeps the server from ever freeing any of it. { calif_io }

A single attacker can consume up to 32 GB of RAM on the target system, making this attack highly effective. For more details and a technical deep-dive, please read that excellent article and writeups for each affected server, its very detailed.

Affected:

  • nginx
  • Apache httpd
  • Microsoft IIS
  • envoy proxy
  • cloudflare pingora

There have been no statements regarding this issue for HAProxy/Varnish so far; however, this should become clear over the next few days. Since the bug is an HTTP/2 protocol bug, other services may also be affected.

With Nginx (HW load balancers, the most popular open-source reverse proxy, ingress controller for Kubernetes), Envy (reverse proxy for large cloud and tech companies such as Google, Amazon, Netflix, and Airbnb), and IIS (Azure), a large portion of modern public-facing web infrastructure is affected

When stuff goes OOM

Given these circumstances, we had to take a close look at the writeup and assess the impact in order to determine which of our customers were affected and to incorporate the new attack vector directly into our platform.

And, oh boi, that attack is effective. With one single notebook we were able to bring down ANY of our own HTTP/2 servers, small and large.

findings

  • one single attacker can cosume 20-30 GB of RAM on the target
  • RAM/memory remains locked even after the attack is stopped; this allows for a “low & slow” attack, in which the attacker starts with a low connections/streamrate but gradually consumes more and more of the target's resources over time (see screenshots)
  • Once a certain RAM usage threshold is reached, the affected Nginx instance crashes and must be restarted via a hard reboot (permanent damage)
  • With these attacks, even a small botnet of 10 bots can take down services of any size; for a low-and-slow attack with fewer than 10 RPS in initial requests, a botnet of 100 bots is sufficient; such an attack would be undetectable and unstoppable by any WAF

Memory locked after a single testrun with 1 connection

Below are our test cases for verification against different targets

case 1 / single node + pulsewave

  • target: nginx 1.28 on ubuntu 24 LTS, no special options, 8 CPU, 16 GB RAM
    RAM-baseline 8%
  • attacker-side:
    • 1 node, 5 streams, 30 sec holds, drip every 5 sec
    • attack-mode: low & slow with pulswave, max 20 RPS every 15-30 seconds, in a loop
  • after 7 pulses, ca 5-6 minutes, target is OOM, nginx crashes, after crash -> no recovery
Attack-Pulses and RAM-Usage on the target
Connection refused for the attacker after nginx crashes

Attack-Pulses and RAM-Usage on the target, explained

case 2 / 10 nodes botnet + pulsewave

  • target: nginx 1.28 on ubuntu 24 LTS, no special options, 8 CPU, 16 GB RAM
    RAM-baseline 8%
  • attacker-side:
    • 10 node, 1 streams, 30 sec holds, drip every 5 sec
    • attack-mode: low & slow with pulswave, max 40 RPS every 15-30 seconds, in a loop
  • after 7 pulses, ca 5-6 minutes, target is OOM, nginx crashes, after crash -> no recovery
  • advantage vs single node: even less RPS per node, even harder to detect and defend from a WAF

Attack-Pulses and RAM-Usage on the target

RPS on the target during attack

target killed after 3 minutes

case 3 / 10 nodes botnet + pulsewave

  • target: F5 Big IP Loadbalancer - under embargo

Not affected:

  • nginx 1.18 (Debian 11)

As of now, the attack is available in our Avydos-Platform for all subscription-tiers. Need more info on that?

Contact us for a Demo

Credits

  • calif_io for detecting the bug and delivering the writeup and POCs
  • unnamed engineer @ F5 for helping us
  • zeroBS -team for fast reacting, setup testbeds and implementing the new attack-vectors into our platform within 24hrs

Ressources