A remote, unauthenticated client can force an HTTP/3 server to allocate tens to thousands of times more memory than it sends. One connection is enough to run a server out of memory or pin a default-configured server. Seven of the ten implementations tested are vulnerable, and several have already been fixed.
QPACK compresses HTTP/3 headers to minimize traffic sent over the wire. Across the affected implementations, decoded-header limits are missing, incomplete, or applied too late. A small HEADERS frame can therefore expand into hundreds of thousands of header objects in memory. Preventing that expansion requires enforcing a cumulative budget as fields are decoded and retained.
The research began while studying QUIC stacks for the TLS scanner JA4Scan, where the same vulnerability class appeared across multiple HTTP/3 implementations. RFC 9114 defines how servers should limit decoded header size, but some implementations check only the compressed frame size, decompress everything before checking, omit the 32-byte per-field overhead, default to unlimited when the setting is unconfigured, or never enforce the setting at all.
The attack works in two directions. A 1,000,000-byte HEADERS frame can hold about 160,000 unique headers, while a dynamic table variant inserts one large entry and references it thousands of times with one-byte indexes, producing a ratio of 4064:1 in lsquic and Bun.
quic-go, Cloudflare quiche, lsquic and Wireshark have fixes available. Bun, the h3 crate and aioquic/mitmproxy remained unpatched as of October 20, 2026, and mitigations include not exposing HTTP/3 servers, disabling HTTP/3 in mitmproxy, and setting a reasonable max_field_section_size in h3. IIS, Envoy and ngtcp2/nghttp3 are not affected.
Source: Hacker News · Summarized by HeadlinesBriefing