One Connection, Out of Memory: QPACK Flaws Hit Seven HTTP/3 Stacks

HTTP/3 was meant to make the web faster. A newly disclosed class of bugs in its header-compression layer shows it can also make some servers fall over — from a single unauthenticated connection, with no login and no special access.

What happened

Researchers at FoxIO tested ten HTTP/3 implementations and found the same weakness in seven of them. It sits in QPACK, the mechanism HTTP/3 uses to shrink request headers by replacing repeated fields with short references to a shared table.

The problem is where the size limit is enforced. A server is expected to cap how large a header set may become after it is decoded. The affected stacks either check only the compressed bytes arriving on the wire, or apply the cap too late. An attacker can therefore send a compact batch that the server expands into hundreds of thousands of header entries — all held in memory.

Two techniques were demonstrated:

• Bulk expansion — in FoxIO's tests against quic-go defaults, roughly 1 MB of compressed input unpacked into about 160,000 header fields and ~15 MB of memory (around 17×; the project's own advisory puts the theoretical ceiling near 50×).
• Reference amplification — store one ~4 KB header once, then point at it thousands of times with one-byte references. The server rebuilds the full entry each time: about 4,000× on Bun and 600–1,800× on lsquic in testing.

Bun is the worst case. Its HTTP/3 server (still labelled experimental) builds on lsquic but swaps out the code that limits header memory, checking each header individually but never the running total. Past 2 GB of decoded headers a size counter wraps to zero and the server spins at 100% CPU indefinitely — triggered by a single stream of roughly 516 KB.

Who is affected

Status as of 22 October 2026:

The blast radius is wider than the table suggests, because these libraries sit underneath popular software: quic-go powers Caddy, Traefik and cloudflared; lsquic is inside LiteSpeed Web Server and OpenLiteSpeed.

Wireshark is a separate case: its bug crashes the HTTP/3 dissector when decrypting a capture with key material — it is not a network-reachable server, and the project reports no known exploitation.

IIS, Envoy, ngtcp2/nghttp3 and Google's quiche are reported as not affected, because they enforce the limit while decoding rather than afterwards.

Why it matters

• Denial of service only — there is no indication of data theft or code execution, and no reported in-the-wild attacks so far.
• But the bar is very low: no account, one connection, and because HTTP/3 runs over UDP, the traffic can reach the server before much of the usual HTTP-layer filtering applies.
• Working proof-of-concept code is public, which tends to shorten the window before opportunistic abuse.

What to do

1. Inventory HTTP/3 exposure. Check which internet-facing services advertise HTTP/3 (an Alt-Svc: h3 header or listening UDP/443) and what stack serves them — including Caddy, Traefik, cloudflared and LiteSpeed.
2. Patch now where fixes exist: quic-go ≥ 0.57.0, Cloudflare quiche ≥ 0.29.3, lsquic ≥ 4.9.0, Wireshark 4.6.2 / 4.4.12. Then rebuild and redeploy anything that vendors these libraries.
3. Mitigate where there is no fix:
   • Bun — don't expose its HTTP/3 server.
   • mitmproxy — disable HTTP/3 with --set http3=false.
   • h3 (Rust) — set a sensible max_field_section_size.
4. Consider falling back to HTTP/2 on critical endpoints until your stack is patched; clients will transparently downgrade.
5. Watch for memory spikes and stuck worker processes on HTTP/3 front-ends, and alert on them.

Bugs like this live deep in dependencies most teams never look at directly. Continuous vulnerability scanning of your external surface is how our team flags services running affected HTTP/3 versions — so you know which hosts to patch before someone else finds them.

Research credit: FoxIO (foxio.io). Originally reported by The Hacker News.