New QPACK Flaws Can Crash HTTP/3 Servers, Trigger Up to 4,000-Fold Memory Amplification

A remote attacker who has not logged in can crash many HTTP/3 web servers with a single connection, security firm FoxIO disclosed, releasing working proof-of-concept code.

By sending a small batch of compressed HTTP headers that expands in memory to a much larger set, the attacker can force the server to use thousands of times more memory than it received, enough to run a default server out of memory.

The flaws cause only denial-of-service attacks, with no evidence of data theft or code execution and no public reports of attacks in the wild. Fixes are out for quic-go, Cloudflare quiche, lsquic and Wireshark, but Bun, the h3 Rust library and aioquic were still unpatched at disclosure.

FoxIO found the same class of flaw in seven of ten HTTP/3 stacks it tested. The common cause is in QPACK, the scheme HTTP/3 uses to compress request headers so repeated fields travel as a short code instead of the full text.

A server is supposed to cap the size of the headers after it unpacks them. The affected stacks cap the compressed batch that arrives on the wire, but not the unpacked result, or they apply the cap too late, so a single request can expand into hundreds of thousands of header entries that the server holds in memory.

The reach is wide because these stacks sit under common software. quic-go is the Go library behind Caddy, Traefik and cloudflared; lsquic is LiteSpeed’s library, used in LiteSpeed Web Server and OpenLiteSpeed; and Bun’s HTTP/3 server runs on lsquic.

The attacker needs no account or special access, and since HTTP/3 runs over UDP, the request reaches the server before much of the usual filtering applies.

Which stacks are fixed and which are still exposed, as of October 22, 2026:

FoxIO lists IIS, Envoy, ngtcp2/nghttp3, and Google’s quiche as not affected, each because it caps the unpacked headers while decoding rather than after.

The amplification varies by stack, in FoxIO’s own tests against default settings. On quic-go, a 1 MB compressed batch unpacked into about 160,000 header fields and left roughly 15 MB held in the request, about 17 times the bytes sent; quic-go’s own advisory puts the possible expansion at around 50 times.

A second method drives the ratio much higher: the attacker stores one roughly 4 KB header entry, then points at it thousands of times using one-byte references, and the server rebuilds the full entry on each reference. FoxIO measured about 4,000 times on Bun and between 600 and 1,800 times on lsquic.

Bun carries a worst-case. Its HTTP/3 server, which Bun’s documentation calls experimental, uses lsquic but replaces the part that caps header memory with its own code, which checks each header but never the running total. FoxIO found that once the unpacked headers pass 2 GB, a size counter in that code overflows to zero and the server enters a loop it never leaves.

A single stream carrying about 516 KB on the wire, FoxIO reported, leaves the server stuck at 100 percent CPU with no recovery, blocking new requests. The missing running total is what lets the overflow be reached; lsquic’s own 64 KB cap prevents it.

Wireshark is a different case from the server flaws. Its issue crashes the HTTP/3 dissector, the part that reads HTTP/3 out of a capture, when Wireshark decrypts traffic using a key-log file or opens a capture file that holds decryption secrets. It is not a server an attacker reaches over the network. Wireshark said it is “unaware of any exploits for this issue.”

Operators should upgrade to the fixed releases above. For the stacks with no fix, FoxIO gives interim steps: on Bun, do not expose an HTTP/3 server; on mitmproxy, turn off HTTP/3 by passing –set http3=false; and for the h3 Rust library, set a sensible limit with max_field_section_size.

The lsquic fix, released July 16, 2026, caps how many unpacked header sets a server holds per stream, defaulting to one. FoxIO said the work began after Gal Bar Nahum’s research into “MadeYouReset,” a denial-of-service technique against HTTP/2, which asked whether HTTP/3’s header compression had a similar weakness.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.