FoxIO: QPACK amplification can exhaust memory on seven of ten tested HTTP/3 servers

A new class of HTTP/3 denial-of-service

Security researchers at FoxIO have disclosed a family of memory-amplification vulnerabilities in QPACK, the header-compression scheme HTTP/3 relies on. According to the company's blog post, which reached the Hacker News front page, an unauthenticated remote client can send a request that forces a server to allocate dramatically more memory than the traffic occupies on the wire — up to roughly 4,000 times as much in the worst case. In some cases a single connection suffices to drain a server's memory or hold it at its memory ceiling while running default settings. Seven of the ten implementations the team tested were vulnerable, and several maintainers have already shipped fixes.

The work grew out of FoxIO's QUIC research for JA4Scan, its active TLS scanner, and was inspired by Gal Bar Nahum's MadeYouReset series on HTTP/2 request-cancellation attacks, which raised the question of whether HTTP/3's compression layer had similar weaknesses.

How the amplification works

QPACK replaces repeated header fields with small index references drawn from a static table defined by the specification and a dynamic table built up over a connection. FoxIO points out that a 71-byte strict-transport-security header collapses to a single byte on the wire. RFC 9114 tells servers to cap the decoded size of a field section, counting each field's name and value plus a 32-byte overhead per field. The researchers found implementations that validated the compressed frame size instead of the decoded size, checked limits only after decompressing everything, omitted the 32-byte overhead, defaulted to unlimited, or never enforced the setting at all.

Two attack variants follow from this. In the first, which the researchers call a header accordion, a one-megabyte HEADERS frame is packed with roughly 160,000 uniquely named headers that the server must expand into individual in-memory objects. In the second, the attacker inserts one entry of about 4 KiB into the QPACK dynamic table and then references it thousands of times with single-byte pointers; each reference triggers a fresh allocation and copy of the full entry, for an amplification ratio of about 4,064 to 1.

Affected implementations and fixes

As of October 20, 2026, four of the seven vulnerable projects had patched. quic-go, the Go stack behind Caddy, Traefik and cloudflared, fixed the issue in 0.57.0 (CVE-2025-64702); there, a one-megabyte encoded block decoded into 160,075 fields and about 15 MiB of retained heap. Cloudflare's quiche addressed two problems in 0.29.3 (CVE-2026-12523): the missing 32-byte per-field overhead, and a parser that preallocated buffers from a declared frame length, letting an attacker announce a 16 MiB frame and never transmit the payload. lsquic, which the researchers judged the most deeply affected, was fixed in 4.9.0 in July 2026 with no CVE assigned; in their tests, under 10 MiB of traffic across 50 connections pinned a process against a 5 GiB memory cap within a second. Wireshark's QPACK dissector, which could be crashed by unbounded decoding, was fixed in 4.6.2 and 4.4.12 (CVE-2025-13945).

Still unpatched are Bun 1.4.3, the Rust h3 crate — which panics once a header map exceeds 32,768 entries — and aioquic, used by mitmproxy, which parses the max field section size setting without ever enforcing it. FoxIO's advice for those: do not expose Bun's HTTP/3 server, disable HTTP/3 in mitmproxy, and set a sensible max_field_section_size for h3. Google's quiche, Microsoft's IIS and ngtcp2/nghttp3 were not affected. The researchers also observed production servers advertising QPACK limits, noting that advertised settings are no guarantee a limit is actually enforced.

Why it matters

HTTP/3 over QUIC is now mainstream infrastructure, and this disclosure shows that default deployments across seven independent stacks share the same failure mode: trusting compressed input and validating decoded output too late, if at all. The pattern echoes the HTTP/2 issues that motivated the research, and the remedy is well understood — enforce a cumulative budget on decoded headers incrementally, as each field is decoded and retained, rather than afterwards. Operators running the affected libraries should upgrade immediately, or switch HTTP/3 off where no patch exists yet.