Qpack amplification attacks against HTTP/3 servers

A class of HTTP/3 vulnerabilities lets a remote, unauthenticated client make a server allocate tens to thousands of times more memory than the encoded request on the wire. The problem stems from QPACK header decompression: several implementations either check only compressed size, decompress everything before enforcing limits, omit the RFC-mandated 32-byte per-field overhead, default to unlimited, or never enforce max_field_section_size. By crafting a compact HEADERS frame that expands into many distinct header fields or by inserting one large dynamic-table entry and referencing it repeatedly, a single connection can produce massive in-memory header lists that OOM or pin servers. Seven of ten tested stacks were vulnerable, with amplification observed from ~15x (quic-go) through ~600-1800x (lsquic) up to ~4000x (Bun); some projects have released fixes.

Concrete attack techniques and fixes are described. One variant uses thousands of unique header names (a 1,000,000-byte HEADERS frame can decode to ~160,000 fields); another uses a ~4 KiB dynamic entry referenced thousands of times, forcing copies per reference. Specific failures include quic-go decoding full blocks without decoded-size checks, quiche omitting the 32-byte overhead and preallocating large frame buffers, lsquic lacking cumulative decoded limits, and Bun replacing lsquic’s protections with none. Recommended mitigations are enforcing a cumulative decoded-header budget during incremental decode, advertising and honoring SETTINGS_MAX_FIELD_SECTION_SIZE, suspending parsing when buffers exceed caps, and returning errors (e.g., HTTP 431) on violations.