Small header batches blow up HTTP/3 servers in memory

Seven of ten HTTP/3 stacks cap compressed headers but not the unpacked result, so a slim request can eat gigabytes of memory.

CSBadmin
2 Min Read

One connection. No credentials. No sign-in. That is the entire requirement for knocking an HTTP/3 server into memory exhaustion. FoxIO published working proof-of-concept code after finding the bug in seven of the ten stacks it tested.

The weak point is QPACK, the header compression HTTP/3 relies on. Repeating fields travel as a short code that the receiver expands back into full text. Per the specification, a server should apply its header cap after unpacking. The vulnerable stacks instead limit the compressed bytes on arrival, or enforce the limit once it is already too late, so a single modest request balloons into hundreds of thousands of header entries parked in RAM.

Fixes have landed in quic-go 0.57.0, Cloudflare quiche 0.29.3, lsquic 4.9.0, and Wireshark 4.6.2 and 4.4.12. Still unpatched as of October 22: Bun, the h3 Rust library and aioquic.

None of these are niche projects. Caddy, Traefik and cloudflared all sit on top of quic-go. LiteSpeed maintains lsquic, and Bun’s experimental HTTP/3 server uses it while substituting its own check, which counts each header but never accumulates a total. FoxIO sent one stream of roughly 516KB that overflowed that code and pinned the process at full CPU, with no recovery.

A cheaper variant stores one 4KB header entry and then points at it thousands of times with one-byte references. FoxIO measured amplification near 4,000x against Bun, and between 600x and 1,800x against lsquic.

CSBadmin

The latest in cybersecurity news and updates.

Share This Article
Follow:
The latest in cybersecurity news and updates.