On Wed, Jun 03, 2026 at 09:51:13AM +0200, Willy Tarreau wrote:
> Hi Lukas,
> 
> On Wed, Jun 03, 2026 at 09:45:09AM +0200, Lukas Tribus wrote:
> > Hello,
> > 
> > 
> > FYI there is a new HTTP/2 (HPACK) attack against servers/proxies:
> > 
> > https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb
> 
> Yep I saw it this morning as well, thanks!
> 
> > > HPACK Indexed Reference Bomb: seed the dynamic table
> > > with one header, then emit thousands of 1-byte indexed
> > > references to it. Each reference costs the attacker one wire
> > > byte and the server anywhere from ~70 bytes (nginx, IIS,
> > > Pingora) to ~4,000 bytes (Apache httpd, Envoy) of allocation.
> > >
> > > HTTP/2 Window Stall: advertise a zero-byte flow-control window
> > > so the server can never finish sending its response, then drip
> > > 1-byte WINDOW_UPDATE frames to keep resetting the send
> > > timeout, pinning every allocation in memory for as long as the
> > > server's timeout allows.
> > 
> > 
> > Haproxy is not mentioned in this article; I'm not sure if we are
> > affected or not.
> 
> Indeed it's not. This is about unbounded header decompression. In our
> case the whole headers remain limited to tune.bufsize so we don't have
> this problem.

BTW I found the attack tool and tried it locally. I had to set a
lot of concurrent connections (1000) to observe anything. The result
is amusing:

  $ ps auxw|grep 'haproxy\|python'
  willy    21926  0.9  0.3 577316 53632 pts/3    Sl+  11:08   0:01 ./haproxy 
-db -f h2-h1.cfg
  willy    22277 87.2  0.5 12357272 96488 pts/4  Sl+  11:09   1:28 python3 
/home/willy/hpack_bomb.py --host 127.0.0.1 --port 4443 --connections 1000

It's sort of a "reverse" attack, the attack tool uses twice as much memory
and 100 times as much CPU as the victim ;-)

It's also interesting to note that it's detected by glitches:

  $ socat - /tmp/sock1 <<< "debug counters"
  Count     Type Location function(): "condition" [comment]
  1110       GLT mux_h2.c:2921 h2c_handle_settings(): reduced 
SETTINGS_INITIAL_WINDOW_SIZE

Apparently there's one glitch per connection here. Those who implemented
some filtering for this will quickly detect and block sources using that
script.

Willy


Reply via email to