# QPACK amplification attacks on HTTP/3 servers

> HTTP/3 servers can be overwhelmed by a single client sending compressed headers that expand into thousands of memory allocations.
- Title: QPACK amplification attacks on HTTP/3 servers · Foxio
- Summary: HTTP/3 servers can be overwhelmed by a single client sending compressed headers that expand into thousands of memory allocations. A remote client can force…
- Keywords: qpack, http3, memory leak, security vulnerability, quic, http/3 servers, header compression, amplification attack, technology, startups, amplification, attacks
- Source: Foxio — https://foxio.io/blog/header-accordions-qpack-amplification-attacks-against-http-3-servers
- Published: 2026-10-20T00:00:00+00:00
- Read time: 2 min
- Topics: qpack, http3, memory leak, security vulnerability, quic, http/3 servers, header compression, amplification attack, technology, startups
## QPACK amplification attacks
A remote, unauthenticated client can force an HTTP/3 server to allocate tens to thousands of times more memory than it sends.

> A remote, unauthenticated client can force an HTTP/3 server to allocate tens to thousands of times more memory than it sends.
## Vulnerability impact
One connection is enough to cause an out-of-memory error or pin a default-configured server.

> One connection is enough to cause an out-of-memory error or pin a default-configured server.
## Affected implementations
Seven of ten tested implementations are vulnerable to this attack.

> Seven of ten tested implementations are vulnerable to this attack.
## QPACK compression
QPACK compresses HTTP/3 headers to minimize traffic sent over the wire.

> QPACK compresses HTTP/3 headers to minimize traffic sent over the wire.
## Decoded header limits
Across affected implementations, decoded-header limits are missing, incomplete, or applied too late.

> Across affected implementations, decoded-header limits are missing, incomplete, or applied too late.
## Amplification mechanism
A small HEADERS frame can expand into hundreds of thousands of header objects in memory.

> A small HEADERS frame can expand into hundreds of thousands of header objects in memory.
## Patched as of Oct 20, 2:00
Patches for the vulnerability were released by October 20, 2026.

> Patched as of October 20, 2026
## Fixed versions
quic-go 0.57.0, Cloudflare quiche 0.29.3, lsquic 4.9.0, Wireshark 4.6.2 / 4.4.12 are fixed.

> quic-go 0.57.0, Cloudflare quiche 0.29.3, lsquic 4.9.0, Wireshark 4.6.2 / 4.4.12
## Unpatched versions
Bun 1.4.3, h3 (hyperium), aioquic / mitmproxy remain vulnerable.

> Bun 1.4.3, h3 (hyperium), aioquic / mitmproxy
## Background
The vulnerability was discovered during research into QUIC stacks for a TLS scanner.

> During recent research into the different QUIC stacks for our active TLS scanner, JA4Scan
## Root cause
Decoded-header limits are missing, incomplete, or applied too late across affected implementations.

> Some implementations tested got at least one of these wrong: They check the compressed frame size, not the decoded size
## How it works
A client sends unique header names to create distinct entries in the receiving header map.

> The goal is to maximize the number of headers inside a single HEADERS frame.
## Example attack
A 1,000,000-byte HEADERS frame holds about 160,000 unique headers.

> A 1,000,000-byte HEADERS frame holds about 160,000 unique headers this way.
## quic-go vulnerability
quic-go limits the compressed HEADERS frame but does not enforce a decoded-header budget.

> quic-go is the Go library behind Caddy, Traefik, and cloudflared.
## Cloudflare quiche vulnerability
quiche omits the 32-byte overhead per field and pre-allocates buffers.

> quiche had two issues rolled into one CVE.
## lsquic vulnerability
lsquic has no cumulative decoded limit and unlimited HEADERS blocks.

> lsquic's vulnerability is the deepest I found.
## Bun vulnerability
Bun replaces lsquic's 64 KiB cap with no cap and has a memory leak.

> Bun has a second bug in the same function that turns the amplification into a permanent denial of service.
## aioquic / mitmproxy vulnerability
aioquic parses MAX_FIELD_SECTION_SIZE but never checks it during decoding.

> aioquic is the Python HTTP/3 library used by mitmproxy and hypercorn.
## h3 vulnerability
h3 decodes all headers into a vector and panics when the limit is exceeded.

> h3 is the Rust HTTP/3 library from the hyperium project.
## Conclusion
The protocol provides a way to account for decoded header size but the receiving code must enforce it.

> The protocol already provides a way to account for decoded header size, but the receiving code has to enforce it.
## Key takeaway

A remote client can force HTTP/3 servers to use tens to thousands of times more memory than the original request.