Your HTTP/3 endpoint is only as patched as the QUIC library behind it

On 20 October 2026, FoxIO published full details and proof-of-concept code for "Header Accordions", a QPACK amplification attack against HTTP/3 servers. A remote, unauthenticated client can make a server allocate tens to thousands of times more memory than it sends. Seven of ten implementations tested were vulnerable. Three remain unpatched.
The finding also reminds us that the product name in an inventory is rarely the component that enforces the limit.

What QPACK does and where it breaks

HTTP/3 compresses headers with QPACK. Common field names collapse to a small index, and repeated fields can reference a shared table. That saves bandwidth, and it means a small frame can describe a very large set of headers.
RFC 9114 instructs servers to limit headers by their decoded size, plus 32 bytes of overhead per field. FoxIO found implementations that handled this requirement in several wrong ways. Some checked only the compressed size. Others decompressed everything before checking, skipped the 32-byte overhead, or never enforced a limit at all.
Two variants are described. One fills a frame with a large number of tiny, unique headers. The other inserts one large table entry and then references it repeatedly, so each tiny reference forces a full copy in memory. FoxIO describes the outcome as a small HEADERS frame expanding into hundreds of thousands of header objects in memory.

How each library failed

The per-library findings are the useful part of the report because they map a protocol requirement to a specific code defect.

• quic-go, CVE-2025-64702: capped the compressed frame but not the decoded output, retaining about 15 times the encoded size.
• Cloudflare quiche, CVE-2026-12523: omitted the 32-byte overhead and pre-allocated buffers for frames that never arrived.
• lsquic: amplification of roughly 600 to 1,800 times, described as the deepest case found.
• Bun: removed lsquic's built-in cap.
• aioquic and mitmproxy: the limit is parsed but never enforced.
• h3 (hyperium): an oversized header set can crash a worker thread with a panic.
• Wireshark, CVE-2025-13945: the HTTP/3 dissector could freeze and crash. A second bug in the same area can leave a server stuck at 100% CPU permanently, which is a different failure mode from memory exhaustion and one that survives a restart of the offending connection.

The limit was advertised; nobody enforced it

FoxIO's central argument concerns ownership more than code. QUIC counts bytes, the QPACK decoder rebuilds fields, and the application stores them. The report asks which component actually rejects the oversized headers, and observes that an advertised limit can look reassuring while providing no protection.
The question has a direct operational consequence. A stack can present a configured maximum header size in its documentation, its TLS scanner profile and its configuration file, while the code path that receives the frame never consults it. Checking the configuration value proves nothing about enforcement.

Fixed versions, and the ones still open

Patched as of 20 October 2026: quic-go 0.57.0, Cloudflare quiche 0.29.3, lsquic 4.9.0 (no CVE assigned), Wireshark 4.6.2 and 4.4.12.
Still unpatched at the time of reporting: Bun 1.4.3, the h3 crate for hyperium, and aioquic together with mitmproxy.
Not affected in FoxIO's tests: Microsoft IIS, Envoy, Google quiche, and ngtcp2 with nghttp3, all of which enforced limits correctly.
The CVE numbering in the report is worth reading carefully. CVE-2026-12523 maps to quiche with a 7.5 score. CVE-2025-13945 maps to Wireshark at 5.5. CVE-2025-64702 maps to quic-go at 5.3. lsquic has no CVE despite the highest measured amplification, which means a CVE-driven inventory will not find it.

What to do with an HTTP/3 service

1. Identify the library, not the product. Caddy, Traefik and cloudflared sit on top of quic-go according to the reporting. Container images pin a library version inside them, so a product-level patch note is not proof of what is running.
2. Handle the three unpatched stacks by exposure rather than by configuration. For Bun, do not expose HTTP/3 servers until a fix ships. For mitmproxy, disable HTTP/3 with the http3=false option. For the h3 crate, set a reasonable max_field_section_size.
3. Remember the scanner. Wireshark is on the list. A malformed capture is a plausible way to crash an analyst's tool while they are investigating something else.
4. Use the published fingerprints to find what you cannot see internally. FoxIO released its JA4Scan-QUIC work alongside the report and points to JA4Scan for active TLS and QUIC fingerprinting of affected servers.

Exploitation status and the window

Public proof-of-concept code exists. No source reports use of this QPACK amplification attack in the wild, and none of the three CVEs appears in CISA's known exploited vulnerabilities catalog. The report also notes the work was inspired by MadeYouReset, a 2025 HTTP/2 attack that abused a protocol feature to drain server resources.
The history argues for acting before exploitation appears. A working PoC lowers the cost of the attack to a single connection, and the worst measured ratio in the report was roughly 4,000 to 1. The reporting does not state how many internet-facing HTTP/3 endpoints run an affected stack, so the population at risk remains unmeasured.

References

• SecurityOnline, "PoC and Full Details Released for QPACK Amplification Attack That Crashes HTTP/3 Servers", 22 October 2026: https://securityonline.info/qpack-amplification-attack-http3-poc/
• FoxIO, "Header Accordions" research write-up and public reproduction code referenced in the reporting (published 20 October 2026).
• RFC 9114, HTTP/3 header size constraints referenced by the research.
• FoxIO JA4Scan TLS and QUIC fingerprinting tool referenced for finding affected servers.