CVE-2026-40898

What it actually does

CVE-2026-40898 is a denial-of-service flaw in quic-go HTTP/3 trailer handling. A malicious QUIC/HTTP/3 peer can send a QPACK-encoded HEADERS frame that is small enough to pass compressed-size checks but expands into a very large decoded trailer field section containing many unique field names and/or large values. Vulnerable versions construct Go http.Header objects for those decoded trailers without enforcing decoded field-section limits, causing excessive heap allocation. This can exhaust memory, trigger garbage-collection pressure, kill the process, or crash the service. The issue affects both HTTP/3 servers and clients because both paths construct trailer headers from peer-controlled input.

Why it matters to the business

Organizations using affected quic-go-based software with HTTP/3 or QUIC enabled may be exposed to unauthenticated remote service disruption. An attacker does not need credentials or user interaction and can potentially make public-facing services unavailable by consuming memory. Client applications using quic-go to connect to untrusted or attacker-controlled HTTP/3 endpoints can also be crashed. The current EPSS score is low and stable, the issue is not listed in CISA KEV, and no mature public exploitation is indicated, but the operational risk is still meaningful for internet-facing HTTP/3 services because exploitation is network-reachable and low-complexity.

How an attack unfolds

An attacker first identifies a service or client path that uses a vulnerable version of quic-go with HTTP/3 enabled. For a server-side attack, the attacker establishes a QUIC connection to the target, initiates an HTTP/3 request, and sends a crafted QPACK-encoded trailer HEADERS frame. For a client-side attack, the attacker controls or intercepts an HTTP/3 server endpoint and returns a crafted response with malicious trailers. The encoded HEADERS frame is kept within the implementation's compressed-size limits, but it decodes into a very large trailer field section with numerous unique names and/or large values. The vulnerable implementation allocates memory while building an http.Header representation of the trailers and does not stop based on the decoded trailer size. Repeating this across streams or connections can drive memory consumption high enough to cause latency spikes, process termination, container OOM kills, or full service outage.

How to fix it

Upgrade quic-go to version 0.59.1 or later and rebuild/redeploy all applications, services, proxies, gateways, and client binaries that vendor or statically link the library. Version 0.59.1 enforces RFC 9114 decoded field-section size limits for trailers and aborts streams when trailer decoding exceeds limits. If immediate upgrade is not possible, reduce exposure by disabling HTTP/3/QUIC where feasible, blocking or limiting UDP/443 and other QUIC listener ports at network boundaries, restricting HTTP/3 access to trusted peers, applying request/connection rate limits, and enforcing memory limits with automated restart policies. Because Go applications often compile dependencies into binaries, updating source dependency files alone is insufficient; affected binaries must be rebuilt and redeployed.

How to confirm the fix worked

Confirm dependency resolution shows github.com/quic-go/quic-go at v0.59.1 or later using software composition analysis, SBOMs, go.mod/go.sum review, or `go list -m all | grep github.com/quic-go/quic-go`. For vendored or statically linked applications, verify the deployed binary was rebuilt after the dependency update. Confirm HTTP/3/QUIC exposure by checking listener configuration, reverse proxy settings, and network exposure for UDP/443 or other QUIC ports. In staging, send oversized decoded HTTP/3 trailers and verify the stream is rejected without sustained memory growth or process instability. Monitor runtime memory, container restart counts, and OOM events after deployment to confirm the issue no longer reproduces.

Typical attack path

1. Identify a target application, reverse proxy, API service, or client using vulnerable quic-go with HTTP/3 or QUIC enabled.
2. Establish a QUIC connection to the target server, or lure/configure a vulnerable client to connect to an attacker-controlled HTTP/3 server.
3. Send an HTTP/3 message containing a QPACK-encoded trailer HEADERS frame that is compact on the wire but expands to many unique trailer fields and/or large trailer values.
4. Trigger vulnerable trailer decoding so the implementation constructs a large Go http.Header object without enforcing decoded field-section size limits.
5. Repeat the request, response, stream, or connection pattern to amplify heap allocation and garbage-collection pressure.
6. Cause memory exhaustion, process crash, container OOM kill, degraded performance, or denial of service.

How to detect it

Look for evidence of memory-exhaustion denial-of-service around HTTP/3 or QUIC activity. Useful sources include application logs, Go runtime stderr/stdout, reverse proxy and gateway logs, QUIC/HTTP/3 debug logs if enabled, container runtime events, Kubernetes pod status and events, system logs, kernel OOM killer logs, endpoint telemetry, and network flow records for UDP/443 or other QUIC ports. Investigate unexplained process exits, restart loops, container OOMKilled events, high heap usage, increased garbage-collection pauses, and spikes in QUIC connections or HTTP/3 streams immediately before crashes. Because QUIC traffic is encrypted, network devices usually cannot inspect the malicious QPACK trailer contents unless they terminate HTTP/3; focus on endpoint-side logs and resource telemetry. For client-side exposure, correlate crashes with connections to new, untrusted, or unusual HTTP/3 servers. If HTTP/3 termination logs include trailer metadata, look for abnormal numbers of trailer fields, unusually large trailer values, or stream resets associated with oversized decoded field sections.

• github.com/quic-go/quic-go v0.59.0
• github.com/quic-go/quic-go v0.58.
• github.com/quic-go/quic-go v0.57.
• github.com/quic-go/quic-go v0.56.
• github.com/quic-go/quic-go v0.55.
• github.com/quic-go/quic-go v0.54.
• github.com/quic-go/quic-go v0.53.
• github.com/quic-go/quic-go v0.52.
• github.com/quic-go/quic-go v0.51.
• fatal error: runtime: out of memory
• runtime: out of memory
• signal: killed
• OOMKilled
• Killed process
• memory cgroup out of memory
• oom-kill
• OutOfmemory
• container killed due to memory usage
• UDP/443
• HTTP/3
• h3
• QPACK
• HEADERS frame
• trailers

What your security team should do

• Inventory internet-facing and internal services that enable HTTP/3/QUIC and identify those using quic-go before v0.59.1.
• Prioritize patching exposed HTTP/3 servers, edge services, API gateways, proxies, and clients that connect to untrusted HTTP/3 endpoints.
• Upgrade to quic-go v0.59.1 or later, rebuild all dependent binaries, and redeploy from clean build artifacts.
• Temporarily disable HTTP/3/QUIC or restrict UDP/443 exposure where patching cannot be completed quickly.
• Add monitoring and alerting for sudden memory growth, Go runtime out-of-memory panics, container OOM kills, and spikes in QUIC/HTTP/3 connection or stream activity.
• Review incident telemetry from the period since publication for unexplained restarts, OOM events, and traffic bursts against HTTP/3 endpoints.
• Track downstream products and vendors that embed quic-go, because the library is commonly statically linked and may not appear as a separately patchable package.