HTTP/3

Your HTTP/3 web server might be one small packet away from a total crash, because security researchers at FoxIO just published a working proof-of-concept for a flaw that lets an unauthenticated attacker take down common servers with a single connection, and the root cause sits in how these servers unpack compressed headers, which means a tiny request can balloon into gigabytes of memory and lock your infrastructure solid.

The vulnerabilities cause denial-of-service attacks. There is no evidence of data theft or code execution, and no public reports of attacks in the wild yet. But the fixes are uneven, and some major stacks remain exposed.

How the QPACK Compression Attack Works

To understand the flaw, you have to look at QPACK. That's the scheme HTTP/3 uses to compress request headers so repeated fields travel as a short code instead of the full text.

A server is supposed to cap the size of the headers after it unpacks them.

The affected stacks cap the compressed batch that arrives on the wire, but they don't cap the unpacked result, or they apply the cap too late. An attacker can send a small batch of compressed headers that expands into hundreds of thousands of header entries, forcing the server to use thousands of times more memory than it received.

A default server runs out of memory and crashes.

FoxIO found this same class of flaw in seven of the ten HTTP/3 stacks it tested.

Why This Reach Is So Wide

These libraries sit underneath the software you already use.

quic-go is the Go library behind Caddy, Traefik, and cloudflared. lsquic is LiteSpeed's library, used in LiteSpeed Web Server and OpenLiteSpeed. And Bun's HTTP/3 server runs on lsquic.

Because HTTP/3 runs over UDP, the attack request reaches the server before much of the usual network filtering applies.

The Extreme Amplification and the Bun Infinite Loop

The amplification varies by stack, and some numbers are wild.

On quic-go, a 1 MB compressed batch unpacked into about 160,000 header fields, leaving roughly 15 MB held in the request. That's about 17 times the bytes sent. quic-go's own advisory puts the possible expansion at around 50 times.

A second method drives the ratio much higher. The attacker stores one roughly 4 KB header entry, then points at it thousands of times using one-byte references. The server rebuilds the full entry on each reference. FoxIO measured about 4,000 times amplification on Bun and between 600 and 1,800 times on lsquic.

The Worst-Case Scenario on Bun

Bun carries a specific, nasty flaw. Its HTTP/3 server uses lsquic but replaces the part that caps header memory with its own code, which checks each header but never the running total.

FoxIO found that once the unpacked headers pass 2 GB, a size counter in that code overflows to zero and the server enters a loop it never leaves.

A single stream carrying about 516 KB on the wire leaves the server stuck at 100 percent CPU with no recovery, blocking new requests entirely.

Which HTTP/3 Stacks Are Fixed and Exposed

As of October 22, 2026, the patch status is mixed.

FoxIO lists IIS, Envoy, ngtcp2/nghttp3, and Google's quiche as not affected. Those stacks correctly cap the unpacked headers while decoding rather than after.

Wireshark is a separate case. Its flaw crashes the HTTP/3 dissector when reading a capture file, not a live server over the network.

How to Protect Your Infrastructure Right Now

If you run a fixed stack, upgrade immediately.

For the stacks with no fix, FoxIO provided interim steps to reduce exposure:

• On Bun: Do not expose an HTTP/3 server to the internet.
• On mitmproxy: Turn off HTTP/3 by passing --set http3=false.
• On the h3 Rust library: Set a sensible limit with max_field_section_size.

The lsquic fix, released July 16, 2026, caps how many unpacked header sets a server holds per stream, defaulting to one.

Why This Bug Surfaced Now

FoxIO said the work began after Gal Bar Nahum's research into "MadeYouReset," a denial-of-service technique against HTTP/2. That research asked whether HTTP/3's header compression had a similar weakness.

It did. And the proof-of-concept proves it.

The lesson is structural. As more of the internet shifts to HTTP/3, the underlying libraries need the same scrutiny we applied to HTTP/2. A single unauthenticated packet shouldn't be able to bring down a production server.

FAQ

What is the HTTP/3 denial-of-service flaw?

It is a flaw in how several HTTP/3 stacks handle QPACK header compression. An unauthenticated attacker can send a small compressed batch that expands into massive memory usage, crashing the server.

Which stacks are fixed?

quic-go 0.57.0, Cloudflare quiche 0.29.3, lsquic 4.9.0, and Wireshark 4.6.2 / 4.4.12 are fixed. Bun, h3 (hyperium), and aioquic / mitmproxy remain unpatched.

Does this flaw allow data theft or code execution?

No. FoxIO confirmed the flaws cause only denial-of-service attacks.

How do I protect an unpatched Bun server?

FoxIO recommends not exposing an HTTP/3 server to the internet if you are running Bun.

Has this flaw been exploited in the wild?

There are no public reports of attacks in the wild as of October 22, 2026.

Source: The Hacker News