Researchers have uncovered multiple vulnerabilities in QPACK, the HTTP/3 header-compression mechanism, allowing unauthenticated attackers to crash servers by triggering massive memory usage. By sending a small compressed batch of headers that expands into a far larger structure in memory, an attacker can amplify resource consumption by thousands of times—causing server crashes under default configurations.
What’s the issue and how bad is it?
The flaws enable memory amplification attacks: an attacker crafts minimal compressed HTTP/3 headers, which, when decompressed by the server, translate into an enormous number of header entries. Some affected server stacks limit the compressed data but either omit strict limits on the decompressed expansion or apply them too late. That allows the expansion to overwhelm server memory, potentially leading to denial of service.
Tests show different degrees of amplification. For instance, in one scenario quic-go expanded a 1 MB compressed payload into about 160,000 header fields, holding 15–17× the bytes sent. But worse cases show amplifications around 600–1,800× for certain stacks, and up to ~4,000× in libraries like Bun under specific conditions.
Affected libraries, patches, and mitigation steps
The security team identified this problem in 7 out of 10 HTTP/3 implementations. Some of the major affected stacks and their patch status as of October 22, 2026:
- quic-go: patched in version 0.57.0
- Cloudflare quiche: fixed in version 0.29.3
- lsquic: fixed in version 4.9.0
- Wireshark: fixed in versions 4.6.2 and 4.4.12 (issue affects the HTTP/3 dissector in captures, not live network servers)
- Unpatched stacks: Bun, h3 (Rust), aioquic/mitmproxy haven’t released fixes yet
Some server/library setups, like Bun’s HTTP/3 server, use lsquic but replace its header memory-capping logic with custom code that fails to track running totals. In Bun, once unpacked headers exceed about 2 GB, a size counter overflow causes an infinite loop and full CPU usage until service is stuck.
What you should do now
For operators using any of the stacks mentioned, immediate action is recommended:
- Upgrade to fixed versions wherever available.
- If using Bun or another unpatched stack, disable HTTP/3 exposure until a patch is released.
- Configure sensible limits (like max_field_section_size or similar settings) on unpacked header size.
HTTP/3 traffic uses UDP, which means filtering that relies on TCP rules or port-based inspection won’t catch these attacks early. An attacker needs no authentication or special privileges to trigger the flaw—just network access to send an HTTP/3 request.
The vulnerability class ties back to “MadeYouReset” attacks in HTTP/2, which exploited bulk header compression weaknesses. Here in HTTP/3, the same principle applies but in new stacks that haven’t properly bounded decompressed headers.
Right now, there is no evidence these flaws have been exploited in live attacks. The attack class causes denial of service only—not data leakage or code execution. But unmitigated, this could allow attackers to degrade or take down services at scale.
Analytically, these flaws expose the risks of compression-based optimizations like QPACK: while they improve performance by reducing bandwidth, they also introduce expansion vulnerabilities whenever limits are applied only to compressed data. Key takeaway for developers and operators is that the gap between “data received” and “data processed in memory” must always be bounded. Stakeholders will need to revisit buffer, header, and resource-limiting settings across HTTP/3 stacks—especially those that ship with conservative defaults. Keep live systems patched, disable untrusted protocols proactively, and architecture design defensively to avoid being an easy target for amplification DoS attacks.
