A single connection can exhaust HTTP/3 server memory through QPACK flaws

October 22, 2026. Security firm FoxIO publishes a class of flaws in QPACK, the header-compression scheme used by HTTP/3, and releases working proof-of-concept code. October 22, 2026. Fixes are already out for quic-go, quiche and lsquic, but Bun, the Rust h3 library and aioquic remain unpatched. No exploitation has been observed in the wild. Why it matters: an unauthenticated attacker can take down an HTTP/3 server with a single connection, turning a few kilobytes on the wire into hundreds of thousands of in-memory header entries.

QPACK compresses headers, and that is where it breaks

HTTP/3 swaps TCP for UDP and replaces the HPACK header compression of HTTP/2 with QPACK, defined in RFC 9204. The idea is the same: header fields that repeat — user-agent, cookie, the long values of an API call — travel once in full and are then referenced by a short code. That is what keeps the protocol cheap on the wire.

The implicit contract is simple: a server must cap the size of the headers after decompression, not just the size of the packet it receives. FoxIO found that seven of the ten HTTP/3 stacks it tested cap the compressed batch arriving on the wire but not the unpacked result, or apply the cap too late. A single request can then balloon into several hundred thousand header entries the server holds in memory.

The wire is capped, the decompression is not

The flaw is an amplification imbalance. FoxIO measured, against each stack’s default settings, what a compressed batch becomes once unpacked. On quic-go, 1 MB compressed unpacked into about 160,000 header fields and left roughly 15 MB held in the request — about 17× the bytes sent; quic-go’s own advisory puts the possible expansion at around 50×.

A second method drives the ratio far higher. The attacker stores one entry of roughly 4 KB, then points at it thousands of times with one-byte references, and the server rebuilds the full entry on every reference. FoxIO measured about 4,000× on Bun and between 600× and 1,800× on lsquic. The result is pure denial of service: no data theft, no code execution, just a machine that collapses under its own memory.

The attack is easy to trigger because it needs no account and no privilege. Since HTTP/3 runs over UDP, the request reaches the server before most of the filtering that normally applies to TCP. The vector is not an application-layer zero-day: it is the protocol itself rewarding the asymmetry between what is sent and what is stored.

The stacks affected

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

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. That is exactly the control the vulnerable stacks are missing.

Bun: the worst case

Bun compounds the problems. Its HTTP/3 server, which the documentation calls “experimental”, relies on lsquic but replaces the part that caps header memory with its own code — code that checks each header individually but never the running total. FoxIO found that once the unpacked headers pass 2 GB, an internal size counter overflows to zero and the server enters a loop it never leaves. A single stream of about 516 KB on the wire leaves the process stuck at 100% CPU with no recovery, refusing new requests.

The missing running total is what makes the overflow reachable; lsquic’s own 64 KB cap prevents it. On Bun, the only sane measure until a fix lands is to not expose an HTTP/3 server. For mitmproxy, turn off HTTP/3 with --set http3=false; for the Rust h3 library, set an explicit limit via max_field_section_size.

Wireshark, a separate case

Wireshark is not a server an attacker reaches over the network: its flaw crashes the HTTP/3 dissector, the part that reads HTTP/3 out of a capture, when the tool decrypts traffic using a key-log file or opens a capture that holds decryption secrets. Wireshark says it is unaware of any exploitation. The impact is an analyst tool that crashes, not an exposed attack surface — but anyone processing QUIC captures should still move to 4.6.2 or 4.4.12.

Verdict

If you expose an HTTP/3 server, the first question is not “am I vulnerable?” but “which stack runs underneath?”. Behind Caddy, Traefik or cloudflared, that is quic-go: move to 0.57.0. Behind LiteSpeed or OpenLiteSpeed, that is lsquic: move to 4.9.0. If you run Bun, disable the HTTP/3 server — it is the only safe path today, since the 2 GB overflow makes the crash unrecoverable. If you maintain an h3-based service, set max_field_section_size, and on mitmproxy, switch HTTP/3 off until aioquic is patched.

Beyond the immediate fix, take the structural lesson: the move to HTTP/3 shifted the attack surface to UDP and to header decompression. This is not an isolated incident — FoxIO began this work after Gal Bar Nahum’s research into MadeYouReset, a denial-of-service technique against HTTP/2. The underlying question is the same one we raised about Cloudflare’s BGP filtering: when a protocol moves trust from the network to the application, the application has to do the capping the network will no longer do for it.

References

• The Hacker News — New QPACK Flaws Can Crash HTTP/3 Servers, Trigger Up to 4,000-Fold Memory Amplification
• FoxIO — Header Accordions: QPACK Amplification Attacks Against HTTP/3 Servers
• GitHub — quic-go advisory CVE-2025-64702
• GitHub — Cloudflare quiche advisory CVE-2026-12523
• Wireshark — wnpa-sec-2025-07