HTTP/3 Vulnerability in QPACK: Should a Small Site Turn Off HTTP/3?

On October 20, 2026, FoxIO researcher Sébastien Féry published "Header Accordions", a write-up on an HTTP/3 vulnerability in QPACK, the header compression HTTP/3 uses. The short version: a remote client with no login can make some HTTP/3 servers allocate tens to thousands of times more memory than it actually sends. FoxIO says one connection is enough to run a default-configured server out of memory or pin its CPU. Seven of the ten implementations it tested were vulnerable.

That sounds scary, and the first question I got was the obvious one: should a small business site just turn HTTP/3 off? For most sites, no. Here's why, and the few cases where I would.

• This is a denial-of-service bug, not a break-in. The risk is your site going down, not someone stealing data or running code.
• Most of the big libraries are already fixed, some of them months ago: quic-go, Cloudflare quiche, lsquic (the engine inside LiteSpeed) and Wireshark. Bun shipped its fix on October 22.
• Updating beats disabling. If your server software is current, you're likely already covered.
• Turn HTTP/3 off if you can't update or can't tell what's serving it. Browsers fall back to HTTP/2 on their own, so the cost is small.
• On Vercel there's nothing to do. Its CDN doesn't list HTTP/3 as a supported protocol.

HTTP/3 compresses request headers with QPACK. Common headers get sent as a tiny index number instead of the full text, and the client and server also build a shared "dynamic table" of headers they've already seen. That's good for speed. It also means a small number of bytes on the wire can stand for a lot of data once the server decodes it.

The HTTP/3 spec tells servers how to limit this: count the decoded size of the headers, plus 32 bytes of overhead per field. FoxIO found implementations that got that wrong in five different ways. Some checked only the compressed size. Some decoded everything before checking. Some left out the 32-byte overhead. Some defaulted to no limit, and some advertised a limit they never enforced.

FoxIO showed two ways to abuse it. One packs about 160,000 tiny unique headers into a single 1 MB frame. The other puts one large header, around 4 KiB, into the dynamic table and then references it thousands of times with one-byte pointers. Each pointer makes the server copy the full header again. That second trick is where the biggest numbers come from.

Two details are worth knowing. First, a lot of this was fixed quietly before the write-up. FoxIO's timeline shows quic-go shipping its fix in November 2025, and quiche and lsquic shipping theirs in July 2026. The October 20 post was the public disclosure, not the patch date. Second, the severity ratings are about availability only. The quic-go advisory rates it 5.3 (moderate), and the quiche advisory rates it 7.5 (high), with no impact on confidentiality or integrity in either.

The "7 of 10" figure is FoxIO's own count of the implementations in its main results table. The lead I got also said Bun was unpatched. That was true when FoxIO published, but a Bun maintainer closed the report on October 22, saying the fix is in Bun 1.4.4.

My rule is simple. Update first. Disable only if you can't update, or can't find out what's actually serving HTTP/3.

Turning HTTP/3 off is cheap. Browsers discover HTTP/3 through a header your server sends, and if it isn't there they use HTTP/2 like they always have. Your visitors won't see an error. You give up some speed on bad mobile connections, and that's about it.

But turning it off doesn't fix anything. If the library is out of date, the next bug will find you too. Most small sites don't run their own QUIC stack anyway. They're on shared hosting, LiteSpeed, nginx or behind a CDN. The useful work is figuring out which of those you are.

First, check whether your site even offers HTTP/3. From any terminal:

curl -sI https://yourdomain.com | grep -i alt-svc

If you see h3 in the result, something in front of your site speaks HTTP/3. If you see nothing, you probably don't, and this isn't your fire.

On shared hosting, you usually don't control this, so ask your host directly: "Do you serve HTTP/3, and is your server built on lsquic 4.9.0 or later?" A host running LiteSpeed should be able to answer in one line.

If you run your own cPanel server, find out what's answering on port 443. If HTTP/3 is coming from LiteSpeed, read the next section. If it's coming from a CDN in front of the server, read the Cloudflare section.

This is the case I'd look at hardest. lsquic, LiteSpeed's QUIC library, showed some of the largest amplification FoxIO measured, about 600x to 1,800x. FoxIO's own fingerprint table lists OpenLiteSpeed 1.9.1 shipping lsquic 4.8.2, which predates the fix.

• OpenLiteSpeed: version 1.9.2 (August 6, 2026) updated lsquic to 4.9.3, and 1.9.3 (September 29) moved to 4.10.0. If you're on 1.9.1 or older, update.
• LiteSpeed Enterprise: the 6.3 changelog shows build 3 (July 27, 2026) updating lsquic to 4.9.2, and the latest builds from October 22 move to lsquic 4.10.2. Those same October 22 builds also update LiteSpeed's admin PHP binary for the PHP2Shell CVEs, so it's worth installing them either way.
• Can't update today? Turn off HTTP/3 (QUIC) in the LiteSpeed admin until you can.

nginx wasn't in FoxIO's test set, so there's no data on it either way. nginx only speaks HTTP/3 if you added a listen 443 quic line and an Alt-Svc header, so many nginx sites aren't exposed to any HTTP/3 bug at all.

If you did turn it on, keep nginx current. Its security advisories page lists several HTTP/3 fixes this year, unrelated to FoxIO's research. The latest fixed releases are 1.31.7 and 1.30.6. If you don't need HTTP/3, remove the quic listen line and the Alt-Svc header and reload.

Caddy is built on quic-go and serves HTTP/3 by default (its default protocols are h1, h2 and h3). Run caddy build-info and check that the quic-go version is 0.57.0 or newer. Distro packages may backport the fix without changing Caddy's own version number, so check the dependency, not just the Caddy version.

Cloudflare's HTTP/3 toggle lives under Speed > Settings > Protocol Optimization. It controls the connection between visitors and Cloudflare only. Cloudflare doesn't use HTTP/3 to talk to your origin server.

Cloudflare maintains quiche, and the quiche fix has been out since July 14, 2026. I haven't seen a Cloudflare statement about its edge specifically, so I won't claim one.

The real Cloudflare gotcha is your origin. If your server also speaks HTTP/3 directly, and its IP address is reachable, an attacker can skip Cloudflare and hit it head-on. Lock the origin down to Cloudflare's IP ranges, and if you don't need HTTP/3 there, block UDP 443 at the server firewall.

Vercel's CDN docs list HTTPS, HTTP/1.1 and HTTP/2 as the protocols it negotiates, and HTTP/3 isn't on the list. For a Next.js site on Vercel, there's nothing to switch off.

If you serve HTTP/3 straight from an app server, the advice is more direct:

• Bun: update to 1.4.4 or later. Per the Bun pull request, it now enforces the header size limit it advertises and answers 431 to requests over it.
• aioquic, hypercorn or mitmproxy: FoxIO lists these as unpatched. Don't expose their HTTP/3 to the internet. For mitmproxy, FoxIO says to pass --set http3=false.
• Rust's h3 crate: set a sensible max_field_section_size, as FoxIO recommends.

If you're not sure what's serving your site, or whether it's patched, I can check. Email me at caleb@calebdorris.com or get a free quote, and I'll tell you what I find and what, if anything, needs fixing.

What is the HTTP/3 QPACK vulnerability?

It's a class of memory-amplification bugs FoxIO disclosed on October 20, 2026. Some HTTP/3 implementations didn't properly limit how much memory decoded QPACK headers could use, so a small request could force a server to allocate far more memory than it received.

Can the QPACK flaw be used to hack my site?

Not based on what's been published. The reported impact is denial of service: memory exhaustion, a crash or a CPU stuck at 100%. The advisories rate no impact on confidentiality or integrity.

Does turning off HTTP/3 break my site?

No. Browsers fall back to HTTP/2 or HTTP/1.1 automatically when a server doesn't advertise HTTP/3.

Is LiteSpeed affected by the HTTP/3 QPACK vulnerability?

Older builds were, because lsquic was vulnerable before 4.9.0. OpenLiteSpeed 1.9.2 and later and LiteSpeed Enterprise 6.3 build 3 and later bundle a fixed lsquic, according to LiteSpeed's changelogs.

Is nginx affected?

nginx wasn't part of FoxIO's testing, so there's no public answer either way. Keep it on 1.31.7, 1.30.6 or later, and turn HTTP/3 off if you don't need it.

• FoxIO, "Header Accordions: QPACK amplification attacks against HTTP/3 servers"
• oss-security, "Header Accordions: QPACK amplification attacks against HTTP/3 servers"
• quic-go advisory GHSA-g754-hx8w-x2g6 (CVE-2025-64702)
• quic-go v0.57.0 release notes
• Cloudflare quiche advisory GHSA-4fgf-9xrr-88gf (CVE-2026-12523)
• lsquic CHANGELOG
• OpenLiteSpeed 1.9.x release log
• LiteSpeed Web Server 6.3 changelog
• LiteSpeed Web Server changelog
• Bun issue #46475, QPACK amplification
• Bun pull request #46392
• nginx security advisories
• Caddy global options
• Cloudflare, "HTTP/3 (with QUIC)"
• Vercel, "CDN security"