QPACK Amplification: HTTP/3 Server Memory Attacks and Patches

QPACK amplification is a class of HTTP/3 bugs where a small, compressed request makes a server hold far more memory than was sent. FoxIO's research names quic-go, Cloudflare quiche, lsquic, Bun, aioquic and the h3 crate. The first three have fixes. Find which HTTP/3 library your servers and images ship, upgrade it, and turn HTTP/3 off where no fix exists.

What happened

On 20 October 2026, Sébastien Féry of FoxIO published "Header Accordions: QPACK amplification attacks against HTTP/3 servers". The post describes how several HTTP/3 implementations let a remote client, with no login, make the server decode and keep far more header data than it received on the wire. The result is memory exhaustion, and in one case a stuck CPU.

The research is not a single bug in a single product. It is the same mistake made in different ways by different libraries: limits checked against the compressed size instead of the decoded size, limits checked only after everything was decoded, or limits that were advertised but never enforced.

Most of the work was disclosed privately months ago. Three libraries shipped fixes, two with CVEs. Others were still unpatched when the post went out, according to FoxIO.

Timeline

HTTP/3 and QPACK, in plain words

HTTP/3 is the newest version of HTTP. Instead of running over TCP like HTTP/1.1 and HTTP/2, it runs over QUIC, a transport that sits on UDP, usually on port 443. Browsers find out a site supports HTTP/3 through an Alt-Svc response header, then switch to QUIC on the next request.

Every HTTP request carries headers: the path, the host, cookies, user agent and so on. They repeat a lot between requests, so HTTP/2 and HTTP/3 compress them. HTTP/2 uses HPACK. HTTP/3 uses QPACK, defined in RFC 9204.

QPACK works with two lookup tables:

• A static table of common header names and values that every implementation knows, such as :method GET.
• A dynamic table that the two sides fill during a connection, so a long header sent once can later be referred to with a short index. RFC 9204 counts each entry as name plus value plus 32 bytes, and the table starts at zero capacity until the decoder allows more.

That design is what makes headers cheap to send. It is also why the size on the wire and the size in memory can be very different. A one byte reference can stand for a long entry. Many short references can expand into many full header lines.

The HTTP/3 standard plans for this. RFC 9114 section 4.2.2 says header size is measured on the decoded fields: the length of each name and value plus 32 bytes of overhead per field. A server can advertise its limit with SETTINGS_MAX_FIELD_SECTION_SIZE and answer oversized requests with status 431. By default the setting is unlimited, so the server has to set and enforce it.

Why amplification matters

Amplification here means the attacker sends a little and the server spends a lot. FoxIO measured the ratio between bytes on the wire and memory held by the server. The numbers it reports range from about 15 times for quic-go to hundreds or thousands of times for others. A server with a few gigabytes of RAM can run out without the attacker needing much bandwidth.

FoxIO groups the root causes into a short list. In our words:

1. Checking the wrong number. The library capped the compressed frame, not the decoded headers.
2. Checking too late. It decoded everything first and checked the limit afterwards, when the memory was already spent.
3. Counting wrong. It skipped the 32 byte per field overhead that RFC 9114 requires, so many tiny headers slipped under the limit.
4. Defaulting to unlimited. The limit existed but was zero, meaning no limit, unless the operator set it.
5. Advertising without enforcing. The server told clients a limit in its settings and then accepted more.

None of this needs authentication. It happens while the server is still reading the request, before your application code or login checks run. That is why it is a server and library problem, not an application problem.

FoxIO has published proof of concept material on GitHub, which is a reason to patch now rather than later.

Who is affected

The table below combines FoxIO's findings with what each project's own advisory or release page says. "Status" is as of FoxIO's post on 20 October unless noted.

A few notes on the table:

• quic-go. The quic-go advisory says versions 0.56.0 and earlier are affected and both HTTP/3 clients and servers can be hit, because the same decode path is used both ways. A second advisory in May 2026 covers the same problem in trailers, fixed in 0.59.1. If you are upgrading anyway, go to 0.59.1 or later.
• quiche. Cloudflare's advisory and the CVE record list two problems: some HTTP/3 frames made quiche reserve memory based on a declared length the attacker never had to send, and QPACK limits were not applied correctly. Every version from 0.1.0 up to 0.29.3 is listed as affected.
• lsquic. The 4.9.0 release note reads "Limit number of buffered header sets to cap memory use." FoxIO says the fix adds an es_max_header_sets setting with a server default of 1. lsquic shipped further QPACK fixes in 4.9.2 and 4.9.3, so the newest 4.10.x release is the sensible target.
• Wireshark. This one is about analysts, not servers. The vendor advisory describes a crash when decrypting HTTP/3 traffic with a key log or opening a capture that carries decryption secrets. It credits Sébastien Féry.
• Bun, aioquic and h3. The impact claims come from FoxIO. We found no vendor advisory or release note with a fix for any of them. On 22 October, Bun's GitHub tracker gained an issue titled as a QPACK dynamic table amplification risk, and the h3 tracker gained an issue and two pull requests to bound decoded header memory with a finite default limit. aioquic's tracker showed nothing on this as of 22 October. Treat these as reported and in progress, not fixed.

Where these libraries hide

Most teams do not pick a QUIC library directly. They get one inside something else. Some examples we could confirm:

• Caddy depends on quic-go. Its current go.mod requires quic-go 0.63.0. Fedora's bug tracker shows Caddy packages rebuilt with quic-go 0.57.0 for CVE-2025-64702 and pushed to stable on 2 July 2026. If you run an older Caddy binary or a distro package that was not rebuilt, check it.
• OpenLiteSpeed bundles lsquic. Its release log shows 1.9.2 (6 August 2026) moving to lsquic 4.9.3 and 1.9.3 (29 September 2026) moving to 4.10.0. FoxIO's fingerprint list includes OpenLiteSpeed 1.9.1 with lsquic 4.8.2 as an affected build.
• curl can be built with quiche as an HTTP/3 backend, which curl labels experimental; its main backend is ngtcp2 with nghttp3. A curl built on quiche is a client, but quiche's advisory covers the HTTP/3 layer in general.
• mitmproxy uses aioquic for HTTP/3.
• Any Go service that imports quic-go/http3 directly, and any Rust service using quiche or h3, carries the library in its own binary. Upgrading the operating system does not fix those.

FoxIO tested a set of open source stacks plus IIS. Its post does not cover every HTTP/3 server, so a product that is missing from the table is not known to be safe or unsafe. Check your vendor.

A related but separate QPACK issue

QPACK memory bugs are not limited to FoxIO's list. Netty published advisory GHSA-495p-pchh-r4mc on 10 September 2026: its HTTP/3 QPACK encoder could keep per stream tracking state forever if a client withheld acknowledgments. It affects io.netty:netty-codec-http3 4.2.0.Final through 4.2.17.Final and is fixed in 4.2.18.Final. The GitHub advisory lists no CVE; some vulnerability databases attach one, so search by the GHSA ID. This is not part of FoxIO's research, but it is the same family of problem and worth fixing in the same pass.

What to do now

1. Find out whether you serve HTTP/3 at all. Check for an Alt-Svc header advertising h3, and for something listening on UDP 443.

   curl -sI https://your.site | grep -i alt-svc
   sudo ss -ulpn | grep ':443'
   

   If your curl was built with HTTP/3 support (curl -V lists HTTP3 under Features), you can also try curl -sI --http3-only https://your.site.

2. Check Go services for quic-go. In a module, ask Go. For a compiled binary, read its build info.

   go list -m github.com/quic-go/quic-go
   go version -m ./your-binary | grep quic-go
   go version -m "$(command -v caddy)" | grep quic-go
   

   Anything below 0.57.0 has CVE-2025-64702. Anything below 0.59.1 has CVE-2026-40898.

3. Check Rust services for quiche and h3.

   cargo tree -i quiche
   cargo tree -i h3
   grep -A1 -E '^name = "(quiche|h3)"' Cargo.lock
   

   quiche below 0.29.3 has CVE-2026-12523. For h3, check that your code sets a finite max_field_section_size.

4. Check LiteSpeed and lsquic.

   cat /usr/local/lsws/VERSION
   /usr/local/lsws/bin/lshttpd -v
   

   On OpenLiteSpeed, 1.9.2 or later carries lsquic 4.9.3 or newer per the release log. If you build lsquic yourself, check the tag you built from and move to 4.9.0 or later, ideally the newest 4.10.x. For the commercial LiteSpeed Web Server and Web ADC, check LiteSpeed's own release notes; we did not verify those versions.

5. Check Python, Bun and Netty.

   pip show aioquic mitmproxy
   bun --version
   mvn dependency:tree -Dincludes=io.netty:netty-codec-http3
   

   For mitmproxy, FoxIO's suggested stopgap is to turn HTTP/3 off with --set http3=false. For Bun, FoxIO's advice is not to expose its HTTP/3 server until a fix ships.

6. Check analyst machines.

   tshark --version | head -1
   

   Wireshark 4.6.2 or 4.4.12 and later fix CVE-2025-13945.

7. Rebuild and redeploy, not just restart. A Go or Rust binary carries the library inside it. Bump the dependency, rebuild the image, redeploy, and then run the version check again against the running artifact.

8. Where there is no fix, take HTTP/3 off the edge. Stop advertising h3 in Alt-Svc and close UDP 443 at the firewall or load balancer. Clients fall back to HTTP/2 over TCP. If a proxy in front of your service terminates HTTP/3 with a library FoxIO lists as not affected, the backend never sees raw QPACK from the internet.

9. Set limits even after patching. Configure a finite field section size where your library exposes one, and give containers memory limits so a bad connection gets one process restarted instead of starving the whole host.

What would have helped

Practices any team can use

Know which network stack you ship. Ask most teams which TLS library their services use and they can answer. Ask which QUIC library and many cannot. An SBOM for each image, kept and searchable, turns "are we running quic-go below 0.57.0?" into a query instead of a week of grepping. Our guide to finding affected products fast covers the inventory side.

Read binaries, not just manifests. HTTP/3 libraries arrive inside compiled tools: a reverse proxy, a CLI, a sidecar. Go and Rust binaries record their dependencies, and scanners can read them. Scan images, not only source repos.

Patch the quiet CVEs too. CVE-2025-64702 scored 5.3. Many teams park medium availability bugs for months. For an internet-facing parser that needs no login, a medium score still means anyone can try it. A rule that raises priority for network-reachable, unauthenticated denial of service in edge components would have pulled this one forward.

Set limits explicitly. Several of these bugs came down to "unlimited by default". Put field section size and header limits in your configuration, with a comment pointing at RFC 9114 section 4.2.2, so the next upgrade does not silently reset them.

Watch memory per process. A sudden climb in resident memory on an edge proxy with flat request rates is a useful alert for this whole class of bug.

The pattern is the same one we saw with edge device zero days this month: code at the edge that parses untrusted input, a fix that exists, and a gap between fix and deployment.

Where Safeguard fits

Safeguard would not have prevented these bugs, and it does not test your running servers for QPACK behavior. It does not check firewall rules, Alt-Svc headers or UDP exposure. Where it helps is the inventory and patching work after a disclosure like this one:

• Finding where a library lives. SBOM and dependency scanning covers repos, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, JSON results under ./output). The platform shows which projects contain a given component and version, so you can ask which images carry quic-go below 0.57.0 or quiche below 0.29.3.
• Matching and ranking. Vulnerability matching against vulnerability databases picks up the CVEs that exist here (CVE-2025-64702, CVE-2026-40898, CVE-2026-12523). Reachability analysis helps separate a service that actually runs an HTTP/3 server from one that only pulls the module in. Issues with no CVE, such as lsquic 4.9.0 or the unpatched Bun and aioquic reports, will not appear as matches; track those by version yourself.
• Holding old versions back. Policies and gates evaluated in the platform can block a build that still carries a vulnerable version.
• Doing the fix work with approval. The Safeguard CLI assistant edits code and runs commands with your approval: bumping quic-go in go.mod, running go mod tidy and the tests, rebuilding the image. Its /permissions modes run from Ask to Strict. Autonomous remediation can open fix PRs; it is off by default.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.

Gold Open Source (gold.safeguard.sh, free, no login) is searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. It is built around open source components, so it is one place to look up fixed versions for a library like quic-go or quiche; confirm against the project's own advisory. For issues with no CVE, the project's release notes remain the source of truth.

Gold Registry (registry.safeguard.sh, paid) provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore-signed, with evidence pages; an artifact loses its badge on regression. We are not claiming it had patched builds of these libraries before the public fixes. The habit it supports is the one that matters here: pull patched, signed components from a curated source and rebuild fast when a fix lands.

Common mistakes

• Upgrading the OS and calling it done. Go and Rust programs bundle their QUIC library. A new distro package of a C library does not change a static binary. Rebuild.
• Checking go.mod but not the deployed binary. The binary in production may predate the change. Run go version -m on what is actually running.
• Trusting "fixed in 0.57.0" for quic-go. The trailer issue needed 0.59.1. Upgrade past both.
• Turning off HTTP/3 in the app but not at the edge. If the load balancer still advertises h3 and terminates QUIC, the exposure is at the load balancer.
• Assuming a limit you advertise is a limit you enforce. That was one of FoxIO's root causes. Test with your own monitoring, not with the setting's name.
• Waiting for a CVE. lsquic's fix has no CVE. Bun and aioquic had no fix at publication. A scanner that only matches CVEs will stay quiet about all three.
• Forgetting the analysts. A malicious capture file can crash older Wireshark builds. Update the laptops of the people who open captures from incidents.

FAQ

What is QPACK?

QPACK is the header compression format for HTTP/3, defined in RFC 9204. It replaces HPACK from HTTP/2 and uses a static table and a dynamic table so repeated header names and values can be sent as short references.

Is QPACK amplification a flaw in the HTTP/3 standard?

No. FoxIO describes it as implementation bugs. RFC 9114 already says header size is counted on decoded fields with 32 bytes of overhead each, and lets servers advertise and enforce a limit. The affected libraries did not enforce that limit correctly, or at all.

Is this being exploited?

We found no public report of exploitation. The CVE record for CVE-2026-12523 shows CISA's assessment of exploitation as "none" at the time it was added. FoxIO has published proof of concept material, so assume that can change.

Does this let attackers run code or steal data?

Not according to the advisories. quic-go and quiche both describe availability impact only: memory exhaustion leading to crashes or denial of service. FoxIO adds a 100 percent CPU loop for Bun and a thread panic for h3.

I use a CDN that terminates HTTP/3. Am I affected?

Your origin is not receiving raw QPACK from the internet if the CDN terminates HTTP/3 and talks to you over HTTP/1.1 or HTTP/2. Whether the CDN itself was affected depends on which stack it uses. Cloudflare's quiche is affected and fixed in 0.29.3, but quiche the library and Cloudflare's edge service are not the same thing; check your provider's notices.

Do HTTP/3 clients need patching too?

For quic-go, yes: its advisory says clients and servers share the vulnerable decode path. A malicious server could hit a quic-go client. Update both.

How do I mitigate if my library has no fix?

Stop advertising HTTP/3, close UDP 443, and let clients fall back to HTTP/2. For mitmproxy, FoxIO suggests --set http3=false. For the h3 crate, set a finite max_field_section_size. Keep memory limits on the process so one connection cannot take down the host.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

The CLI demo is a real session fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json, and runs install and tests with approval. For this incident, you would ask the same assistant to bump quic-go to 0.59.1 or later in go.mod, run go mod tidy and go test ./..., and rebuild the image, approving each step. The demo shows lodash, not quic-go.

Click through it at your own pace, or open it full screen.

The local runner demo shows setting up the runner on your own machine, approving it with its device code, then scanning from the terminal. Here, you would point that scan at the proxy and service images you build to see which ones carry quic-go, quiche or Netty's HTTP/3 codec, and at which versions.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on your computer, a folder choice, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. For a Rust service, the folder would be the repository using quiche, and the edits would be the bump to 0.29.3 or later in Cargo.toml followed by cargo update -p quiche and cargo test, each reviewed before it runs.

Click through it at your own pace, or open it full screen.

To scan the images you build and run, download Safeguard and follow the CLI docs. For the rest of the month, see October 2026 security incidents and what would have helped.

Quick check

Sources

• FoxIO: Header Accordions, QPACK amplification attacks against HTTP/3 servers
• FoxIO blog index
• FoxIO blog_poc repository on GitHub
• quic-go advisory GHSA-g754-hx8w-x2g6 (CVE-2025-64702)
• quic-go advisory GHSA-vvgj-x9jq-8cj9 (CVE-2026-40898)
• quic-go security advisories
• Cloudflare quiche advisory GHSA-4fgf-9xrr-88gf
• Cloudflare quiche security advisories
• CVE-2026-12523 record (CVE Services API)
• lsquic releases on GitHub
• OpenLiteSpeed 1.9.x release log
• Wireshark wnpa-sec-2025-07: HTTP3 dissector crash
• nghttp3 API documentation: nghttp3_settings
• Netty advisory GHSA-495p-pchh-r4mc
• Netty security advisories
• Caddy go.mod
• Red Hat Bugzilla 2488661: CVE-2025-64702 in Fedora Caddy packages
• curl: HTTP/3 support
• RFC 9114: HTTP/3, section 4.2.2
• RFC 9204: QPACK, field compression for HTTP/3
• h3 crate documentation: server Builder
• hyperium/h3 issues and pull requests on max_field_section_size
• Bun issues and pull requests mentioning QPACK
• aioquic issue search
• OpenLiteSpeed docs: commands

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.