🚨HTTP/3 Vulnerability Exposes Servers to Massive Memory Exhaustion
HTTP/3 Servers Vulnerable to Memory Exhaustion Attacks
TL;DR
HTTP/3 servers are vulnerable to attacks that can force them to allocate massive amounts of memory, potentially leading to crashes. Seven of ten tested implementations are affected, but several are already patched.
HTTP/3 servers are under threat from a new vulnerability that allows attackers to force servers to allocate tens to thousands of times more memory than they send. A single connection can cause an out-of-memory (OOM) error or pin a default-configured server. Seven of the ten tested implementations are vulnerable, with several already fixed. This affects developers using HTTP/3, especially those running Caddy, Traefik, and cloudflared, as these rely on the Go library quic-go, which was vulnerable until recently. The vulnerability arises from the QPACK compression mechanism, which can expand small HEADERS frames into hundreds of thousands of header objects in memory. Servers must now enforce a cumulative budget to prevent resource exhaustion. This is a critical update for anyone running HTTP/3 services.
Key Points
Seven of ten HTTP/3 implementations tested are vulnerable to memory exhaustion attacks, with several already fixed.
A small HEADERS frame can expand into hundreds of thousands of header objects, exhausting server resources.
quic-go, the Go library behind Caddy, Traefik, and cloudflared, was vulnerable until recently, now limiting compressed HEADERS frames and enforcing a decoded-header budget.
Cloudflare's quiche had two issues rolled into one CVE, allowing ~1,000,000 one-byte headers to pass before being fixed in version 0.29.3.
lsquic's vulnerability is the deepest, with header_out_dynamic_entry allocating and copying per reference without a cumulative decoded-size limit.
Why It Matters
If you're running HTTP/3 services with Caddy, Traefik, or cloudflared, quic-go's recent update is critical. The update limits compressed HEADERS frames and enforces a decoded-header budget, preventing memory exhaustion attacks. Smaller databases should stay put, but anyone on Aurora Serverless v2 gets this automatically starting November 1.
Comments
Be the first to comment
Enjoyed this article?
Get it daily. 7am. Free. Reads in 5 minutes.
Join 3,569 builders reading daily.