Post cover image

October 31, 2026

One Connection, Seven Crashed Servers: Inside the HTTP/3 QPACK Memory Amplification Vulnerability

How a small HTTP/3 request can consume thousands of times more server memory, trigger denial of service and expose weaknesses in popular…

By White Arrow Cybersecurity

10 min read

How a small HTTP/3 request can consume thousands of times more server memory, trigger denial of service and expose weaknesses in popular QUIC implementations.

Imagine managing a production web server that handles thousands of requests every second.

Your CPU utilisation is normal. Network traffic looks ordinary. There are no suspicious login attempts, no authentication failures and no obvious signs of an intrusion.

Then suddenly, your server starts consuming memory.

Within seconds, the process runs out of available resources and crashes. Your monitoring system reports an out-of-memory event, and legitimate users begin experiencing service interruptions.

Now imagine that the trigger was a single HTTP/3 connection from an unauthenticated remote client.

This is the security issue highlighted by cybersecurity research firm FoxIO in its October 2026 research titled "Header Accordions: QPACK Amplification Attacks Against HTTP/3 Servers."

The research examined ten HTTP/3 implementations and found seven vulnerable to different forms of resource exhaustion.

In some implementations, the memory amplification reached approximately 4,000 times the size of the transmitted data.

This is not a theoretical discussion about protocol complexity. It is a practical reminder that compression, when implemented without proper resource limits, can become a denial-of-service attack vector.

Let's understand what happens technically and what infrastructure engineers should do about it.

1. What Exactly Did FoxIO Discover?

The research identified weaknesses in how several HTTP/3 implementations handle QPACK decompression and decoded HTTP headers.

The central problem is relatively straightforward:

The server limits the size of compressed data but does not adequately limit the size of the data after decompression.

HTTP/3 uses QPACK, defined in RFC 9204, to compress HTTP headers.

Compression reduces the amount of information that needs to travel across the network. However, the receiving server must reconstruct the original headers before processing the HTTP request.

That reconstruction requires memory.

If an implementation does not enforce an appropriate cumulative limit while decoding and retaining headers, a relatively small network payload can generate a disproportionately large amount of memory allocation.

FoxIO demonstrated that a remote, unauthenticated client could exploit this behaviour against vulnerable implementations.

The research found:

  • Seven vulnerable implementations out of ten tested.
  • Memory amplification ranging from tens to thousands of times.
  • Potential server crashes or resource exhaustion.
  • Scenarios where a single connection was sufficient.
  • No authentication requirement for the demonstrated server-side attack scenarios.

Source: FoxIO, 20 October 2026.

2. Understanding HTTP/3 and QPACK

Before examining the vulnerability, let's understand the technologies involved.

HTTP/3 is the third major version of HTTP and operates over QUIC rather than TCP.

QUIC itself uses UDP as its transport layer and provides connection management, encryption and stream multiplexing.

HTTP/3 uses QPACK to compress HTTP headers.

Why is header compression necessary?

Consider a typical HTTP request containing headers such as:

GET /dashboard HTTP/3
:method: GET
:path: /dashboard
:scheme: https
:authority: example.com
user-agent: Mozilla/5.0
accept: application/json
accept-encoding: gzip, br

In real-world applications, many headers repeat across requests.

Instead of transmitting the same information repeatedly, QPACK can use references to entries stored in static and dynamic tables.

This reduces bandwidth consumption and improves efficiency.

However, there is a security consideration.

The server must reconstruct the header fields before the application can process them.

A small encoded reference can represent a much larger header value.

If the server repeatedly allocates memory for these decoded fields without enforcing cumulative limits, memory consumption can increase dramatically.

3. How Does the QPACK Memory Amplification Attack Work?

Think about extracting a compressed archive.

You download a relatively small ZIP file, but after extraction, it contains several gigabytes of data.

The same general concept applies here, although the technical mechanism is different.

In the HTTP/3 attack scenarios documented by FoxIO, an attacker takes advantage of QPACK's header references and the receiving implementation's handling of decoded fields.

There are two particularly interesting approaches.

Technique 1: Large Numbers of Unique Headers

One approach involves creating a HEADERS frame containing a large number of unique header fields.

FoxIO demonstrated that a 1,000,000-byte HEADERS frame could contain approximately 160,000 unique headers.

The receiving implementation then needs to decode these fields and construct the corresponding internal header structures.

The memory cost is not limited to the original strings.

It can also include:

  • Header field objects.
  • String allocations.
  • Map entries.
  • Internal pointers.
  • Slice or array storage.
  • Memory management overhead.

Consequently, the memory required to retain the decoded headers can be significantly larger than the original network payload.

In its quic-go analysis, FoxIO measured approximately 15 MiB of retained memory from a 1 MB encoded header block.

That is approximately 15 times amplification.

Technique 2: Dynamic Table Reference Amplification

The second technique is particularly interesting.

QPACK supports dynamic table entries that can be referenced multiple times.

Imagine an attacker inserting a header entry of approximately 4 KB into the dynamic table.

Instead of repeatedly transmitting the entire 4 KB value, subsequent references can use very small indexed representations.

Each reference can cause the receiving implementation to reconstruct and allocate another copy of the original entry.

In certain vulnerable implementations, this creates a significant difference between the transmitted data and the memory required to process it.

FoxIO demonstrated amplification ratios of approximately:

  • 600–1,800 times in lsquic.
  • Up to 4,000 times in Bun 1.4.3.

The important point is that compression is not inherently dangerous.

The problem is allowing the decompressed output and retained objects to grow without an effective cumulative resource budget.

4. Why Were Seven Implementations Vulnerable?

FoxIO examined ten implementations and identified different root causes.

This was not one shared software bug. It was a class of implementation weaknesses involving decoded-header limits, memory allocation and resource accounting.

Here is the breakdown from the research.

ImplementationIssue identifiedquic-goCompressed size checked without an adequate decoded-header limitCloudflare quicheIncorrect size accounting and excessive frame pre-allocationlsquicMissing cumulative decoded-header limitsBunMissing cumulative limits and an additional CPU exhaustion conditionaioquicHeader-size setting parsed but not enforced during decodingh3 (Hyperium)Oversized header processing could trigger a thread panicWiresharkUnbounded HTTP/3 dissector processing could crash the analyzer

An important clarification: Wireshark is an HTTP/3 traffic analyzer, not a production HTTP/3 server implementation. Its issue is related to processing maliciously crafted traffic during packet analysis.

The other findings concern HTTP/3 protocol implementations or applications built using them.

FoxIO also identified implementations that were not affected in its testing, including IIS, Envoy, Google's quiche and ngtcp2/nghttp3.

This demonstrates why it is important to evaluate the actual implementation rather than assuming every HTTP/3 server is vulnerable.

5. Why Is This Attack Particularly Concerning?

There are three aspects that make this issue important for infrastructure security teams.

A. No Authentication Required

The demonstrated attacks do not require a valid application account or authenticated session.

An attacker does not need to log into the application before attempting to trigger the vulnerable HTTP/3 processing path.

This makes exposed HTTP/3 services particularly important to review.

B. HTTP/3 Uses UDP and QUIC

Traditional web infrastructure monitoring often focuses heavily on TCP traffic, particularly TCP port 443.

HTTP/3 commonly uses QUIC over UDP port 443.

This means that network security controls designed exclusively around TCP connections may not provide equivalent visibility into HTTP/3 traffic.

Security teams should ensure that UDP/443 is included in their network monitoring, firewall policies and traffic analysis.

However, UDP itself is not the vulnerability. The issue is how the receiving application processes QPACK data.

C. Memory Exhaustion Can Affect Service Availability

Consider a production environment where an HTTP/3 server runs inside a container with a 2 GB memory limit.

If an incoming connection causes excessive memory allocation, the container may hit its memory limit and be terminated.

Depending on the deployment architecture, this could cause:

  • Container restarts.
  • Kubernetes pod termination.
  • Increased application latency.
  • Load balancer health-check failures.
  • Service interruptions.
  • Cascading availability problems.

The impact depends on the implementation, resource limits and deployment architecture.

This is why a seemingly small protocol-processing issue can become a serious infrastructure availability problem.

6. Which Products and Libraries Are Affected?

One of the most important findings is that developers and administrators may not directly use the vulnerable library.

It could be bundled inside another product.

For example, FoxIO identified quic-go as the HTTP/3 library used by Caddy, Traefik and cloudflared.

Similarly, lsquic is used by other products, including LiteSpeed-based software.

Here is the remediation status through 31 October 2026.

Library or productFixed version / statusquic-go0.57.0Cloudflare quiche0.29.3lsquic4.9.0Wireshark4.6.2 / 4.4.12Bun1.4.4h3 (Hyperium)Check current maintainer updatesaioquic / mitmproxyCheck current maintainer updates

Relevant identifiers include:

  • CVE-2025–64702: quic-go.
  • CVE-2026–12523: Cloudflare quiche.
  • CVE-2025–13945: Wireshark HTTP/3 dissector.

Bun's corresponding security advisory is GHSA-cf8x-9m69–3gg3 and does not have a CVE assigned in the advisory.

One important update: Bun 1.4.4 was released on 22 October and fixes the issue. Any compiled executable containing an affected Bun runtime must also be rebuilt using the patched version.

Do not assume that upgrading your application automatically upgrades its underlying QUIC implementation. Check the vendor's release notes and dependency versions.

7. Practical Security Assessment: How to Identify HTTP/3 Exposure

This is where infrastructure administrators should start.

Before applying changes, identify which services actually support HTTP/3.

Step 1: Identify HTTP/3 Support

For a public website, inspect its response headers:

curl -I https://example.com

Look for an Alt-Svc header advertising HTTP/3, for example:

Alt-Svc: h3=":443"; ma=86400

This indicates that the server advertises an HTTP/3 alternative.

You can also inspect the response using:

curl -I --http3 https://example.com

Note that your local curl installation must support HTTP/3.

Check its features:

curl -V

Look for HTTP3 in the listed features.

An advertised HTTP/3 alternative is useful evidence, but it does not independently identify the underlying library or prove that a particular vulnerable implementation is running.

Step 2: Identify Your QUIC and HTTP/3 Dependencies

For Go-based applications, inspect your dependency files:

grep -i "quic-go" go.mod

Check the resolved dependency graph:

go list -m all | grep -i "quic"

For Bun:

bun --version

For containerised applications:

docker ps --format "table {{.Names}}\t{{.Image}}"

For Kubernetes:

kubectl get pods -A -o wide

Then review the container image tags and software bills of materials (SBOMs), where available.

For products such as Caddy, Traefik and cloudflared, check the exact release and bundled quic-go dependency rather than assuming that the standalone library version determines product exposure.

Step 3: Review UDP Port 443

Check whether your infrastructure accepts QUIC traffic.

On Linux:

sudo ss -lunp

Review firewall rules:

sudo nft list ruleset

If you use UFW:

sudo ufw status verbose

Remember that allowing UDP/443 does not automatically establish vulnerability. It indicates that QUIC traffic may be reaching the system.

Step 4: Monitor Memory Consumption

For Linux systems, monitor process memory:

ps aux --sort=-%mem | head

For live monitoring:

top

For Docker containers:

docker stats

For Kubernetes:

kubectl top pods -A

Investigate:

  • Unexpected memory spikes.
  • Repeated container restarts.
  • OOMKilled events.
  • Unusual HTTP/3 connection patterns.
  • High CPU utilisation.
  • Unexpected worker process termination.

For Kubernetes, inspect events:

kubectl get events -A --sort-by=.lastTimestamp

These indicators are useful for investigation but are not proof of exploitation.

Step 5: Review Application and Network Logs

Where supported, collect:

  • QUIC connection statistics.
  • HTTP/3 stream metrics.
  • Header decoding errors.
  • Oversized header rejection events.
  • Memory allocation metrics.
  • Container termination reasons.
  • UDP traffic statistics.

The objective is to correlate network activity with application resource consumption.

A sudden increase in memory usage associated with HTTP/3 connections deserves investigation, especially when accompanied by worker crashes or OOM events.

8. What Should Developers Fix in Their HTTP/3 Implementations?

The most important lesson from this research is that limits must be enforced during decompression, not merely after it.

RFC 9114 Section 4.2.2 defines how HTTP field-section size is calculated.

The calculation includes:

  • The length of the header name.
  • The length of the header value.
  • An additional 32-byte overhead for each field.

A simplified expression is:

[ S = \sum_{i=1}^{n} (|name_i| + |value_i| + 32) ]

The server must ensure that the cumulative decoded field-section size remains within an acceptable budget.

Simply checking the compressed HEADERS frame size is insufficient.

Developers should implement:

1. Incremental decoded-size validation

Check the cumulative size as each field is decoded.

Do not wait until the entire header block has been reconstructed.

2. Bounded dynamic table allocation

Limit dynamic table capacity and prevent uncontrolled memory allocation.

3. Header count limits

A large number of tiny header fields can also create significant object and container overhead.

4. Backpressure and stream management

Ensure that excessive decoded data cannot accumulate indefinitely across streams.

5. Safe failure handling

Reject oversized headers or reset the affected stream without crashing the entire server process.

The quic-go 0.57.0 fix provides a useful example: it introduced incremental QPACK decoding and decoded-size checks, rejecting oversized server-side headers with HTTP 431.

9. What If You Cannot Patch Immediately?

If a vulnerable implementation remains in production and an immediate upgrade is not possible, consider reducing the exposed attack surface.

Depending on the software:

  • Temporarily disable HTTP/3.
  • Disable public UDP/443 access where QUIC is not required.
  • Apply connection throttling and appropriate resource limits.
  • Enforce decoded-header limits during processing.
  • Restrict untrusted clients from reaching vulnerable HTTP/3 endpoints.

For mitmproxy, FoxIO recommended disabling HTTP/3 using:

mitmproxy --set http3=false

For the Hyperium h3 library, configure a reasonable max_field_section_size, while verifying that the limit is actually enforced by the implementation.

For Bun, the initial recommendation was not to expose HTTP/3 servers to untrusted clients until the fix was available. Bun 1.4.4 now addresses the issue.

Rate limiting UDP/443 can help reduce exposure, but it is not a substitute for fixing the underlying decompression behaviour.

Also, disabling HTTP/3 does not necessarily require disabling HTTPS. Browsers can generally fall back to HTTP/2 or HTTP/1.1 when HTTP/3 is unavailable.

Test any protocol changes before applying them to production.

10. What Does This Mean for SOC Teams?

From a SOC perspective, this is an interesting availability-focused detection scenario.

Traditional detection strategies often prioritise:

  • Authentication attacks.
  • Malware execution.
  • Privilege escalation.
  • Suspicious outbound connections.
  • Data exfiltration.

However, protocol-level resource exhaustion requires a different approach.

I would recommend creating monitoring and correlation rules around:

Data sourceActivity to monitorNetwork firewallUnusual UDP/443 connection patternsQUIC telemetryAbnormal connection and stream behaviourApplication logsHeader decoding failures and rejection eventsEndpoint monitoringUnexpected process memory growthContainer monitoringOOMKilled events and restart frequencySIEMCorrelation between QUIC traffic and resource exhaustion

One useful detection scenario would correlate a sudden increase in HTTP/3 connection activity with rising process memory and repeated application restarts.

This does not automatically identify a QPACK attack, but it provides a useful starting point for investigation.

Final Thoughts: Compression Should Never Become an Unlimited Resource Allocation Mechanism

The HTTP/3 QPACK research demonstrates how a performance optimisation can introduce a serious availability risk when its implementation does not enforce proper resource limits.

HTTP/3 is not inherently insecure. QPACK is not inherently dangerous.

The problem occurs when implementations trust compressed input without adequately controlling the resources required to decode and retain it.

For infrastructure engineers, the lesson is straightforward:

  • Know which HTTP/3 implementation your application uses.
  • Understand how its QPACK decoder enforces limits.
  • Keep underlying QUIC libraries updated.
  • Monitor UDP/443 traffic.
  • Track memory consumption and container restarts.
  • Test how the service handles oversized decoded headers.

A single connection should never be able to consume an unlimited amount of server memory simply because the receiving application failed to account for decompressed data.

In modern infrastructure security, protecting the network is only one part of the job. You also need to protect the resources consumed by every request that reaches your application.

And sometimes, the biggest availability problem starts with a very small packet.

Accuracy note: This article is based primarily on FoxIO's research published on 20 October 2026, vendor advisories and public updates available through 31 October 2026. The seven-of-ten finding refers to the implementations tested by FoxIO, not every HTTP/3 server on the internet. Wireshark's finding concerns its HTTP/3 dissector. Memory amplification figures are implementation-specific research measurements, not universal guarantees. The issue is primarily a denial-of-service and resource-exhaustion concern; the research does not establish data theft or arbitrary code execution.

Credits: Salil Sardesai