As reported by The Hacker News, security firm FoxIO has disclosed a class of QPACK decompression vulnerabilities affecting seven of ten HTTP/3 implementations tested, with working proof-of-concept code publicly available. This is not a single CVE — it is a pattern failure across an ecosystem, and that distinction matters for defenders triaging priorities today.
Why This Pattern Is Dangerous
The core problem is deceptively simple: HTTP/3 uses QPACK to compress request headers, sending repeated field names as short integer references rather than full strings. The RFC mandates that servers enforce a maximum decompressed header size. Most implementations enforce that limit on the compressed bytes arriving on the wire, or apply it after the decoder has already expanded the payload into hundreds of thousands of entries in memory. A single unauthenticated UDP packet can thus trigger memory consumption orders of magnitude larger than the network payload — a resource-exhaustion amplifier.
FoxIO measured up to ~17x amplification on quic-go using basic field flooding, and up to 4,000x on Bun using a reference-reuse technique where a single 4 KB stored entry is pointed to thousands of times via one-byte references.
Two amplification methods were demonstrated. The first floods the dynamic table with unique entries. The second — more efficient and more dangerous — stores a single large entry and references it repeatedly, forcing the server to reconstruct the full entry on each reference. The second technique is the one defenders should assume attackers will weaponize.
What Defenders Need to Know
The following stacks have identified vulnerabilities. Severity ranges by implementation but is generally High for availability impact (CVSS scores not yet published for all).
| Stack | CVE | Status | Fixed Version | Notes |
|---|---|---|---|---|
| quic-go | CVE-2025-64702 | Fixed | 0.57.0 | Powers Caddy, Traefik, cloudflared |
| Cloudflare quiche | CVE-2026-12523 | Fixed | 0.29.3 | — |
| lsquic (LiteSpeed) | No CVE assigned | Fixed | 4.9.0 | Powers LiteSpeed Web Server, OpenLiteSpeed; Bun HTTP/3 also uses lsquic but Bun itself remains unpatched |
| Wireshark | CVE-2025-13945 | Fixed | 4.6.2 / 4.4.12 | Analysis tool, not a server — but DoS during traffic capture is still a concern for SOC teams |
| Bun | No CVE | Unpatched | — | 4,000x amplification measured |
| h3 (hyperium) | No CVE | Unpatched | — | — |
| aioquic / mitmproxy | No CVE | Unpatched | — | — |
Not affected: IIS, Envoy, ngtcp2/nghttp3, and Google's QUICHE — all cap decompressed header size during decoding, the correct approach.
Who Is at Risk
Any organization running HTTP/3 on an affected stack is exposed. The attack surface is particularly concerning because:
- No authentication required — the request is processed before any login flow
- UDP transport means the packet may bypass L7 WAF rules tuned for TCP traffic
- Single-connection kill — one request can exhaust a default server's memory budget
- Transitive exposure — if you run Caddy, Traefik, or cloudflared, you inherit quic-go's vulnerability even if you never heard of QPACK
CDN and edge-proxy providers using Cloudflare's own quiche are protected post-patch, but organizations running their own reverse proxies on affected libraries — especially in Kubernetes ingress controllers, home-lab setups, and mid-tier hosting — are the most likely to be running unpatched stacks right now.
Shield53 Recommendations — Immediate Actions
- Patch quic-go to 0.57.0+ immediately if you run Caddy, Traefik, or cloudflared. This is the highest-priority fix given its ubiquity in Go-based infrastructure.
- Upgrade Cloudflare quiche to 0.29.3+ and lsquic to 4.9.0+ if applicable.
- For unpatched stacks (Bun, h3, aioquic): disable HTTP/3 at the edge or place it behind a patched reverse proxy that terminates QUIC. If you must run Bun's HTTP/3 server, implement OS-level memory limits per process (cgroups, systemd MemoryMax) and rate-limit UDP connections at the firewall.
- Wireshark: update to 4.6.2 or 4.4.12 to prevent crashes during live capture of malicious QUIC traffic — relevant for blue teams running continuous packet capture.
- Detection: monitor for HTTP/3 connections with abnormally large header field counts or single-connection memory spikes. QUIC traffic with high decompressed-to-compressed header ratios is the indicator. Deploy connection-rate limiting on UDP/443.
- Long term: if your HTTP/3 stack cannot enforce a decompressed header size limit, consider whether HTTP/3 should be enabled at all until the vendor implements RFC-compliant limits. This class of vulnerability will recur in any implementation that defers the size check.
The broader lesson here is ecosystemic: when a protocol specification defines a constraint and multiple independent implementations fail to enforce it the same way, you get a vulnerability class, not a single bug. FoxIO's 7-of-10 hit rate should prompt every QUIC library maintainer to audit their QPACK decoder against the RFC's decompressed-size requirements, not just the ones on this list.
