EUVD-2026-34312
GHSA-vvgj-x9jq-8cj9
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Lifecycle Timeline
2DescriptionGitHub Advisory
Summary
An attacker can cause excessive memory allocation in quic-go's HTTP/3 client and server implementations by sending a QPACK-encoded HEADERS frame that decodes into a large trailer field section with many unique field names and/or large values. The implementation builds an http.Header for the corresponding http.Request or http.Response, while only enforcing limits on the size of the QPACK-compressed HEADERS frame, not on the decoded field section. This can lead to memory exhaustion.
This is very similar to CVE-2025-64702. The difference is that this issue uses HTTP trailers, rather than HTTP headers, as the attack vector.
Impact
A misbehaving or malicious peer can cause a denial-of-service (DoS) attack against quic-go's HTTP/3 servers or clients by triggering excessive memory allocation, potentially leading to crashes or resource exhaustion. This affects both servers and clients due to symmetric header construction.
Details
In HTTP/3, field sections are compressed using QPACK (RFC 9204). Field sections are used for both HTTP headers and trailers. quic-go's HTTP/3 server and client decode the QPACK-encoded HEADERS frame into header fields, then construct an http.Request or http.Response.
http3.Server.MaxHeaderBytes and http3.Transport.MaxResponseHeaderBytes limit the encoded HEADERS frame size, with defaults of 1 MB for servers and 10 MB for clients. However, they did not limit the decoded field section size. A maliciously crafted HEADERS frame carrying trailers can expand to about 50x the encoded size using QPACK static table entries with long names and/or values.
RFC 9114 requires endpoints to enforce decoded field section size limits via SETTINGS, which quic-go did not do for trailers.
The Fix
quic-go now enforces RFC 9114 decoded field section size limits for trailers as well. It incrementally decodes QPACK entries and checks the field section size after each entry, aborting the stream if an entry causes the limit to be exceeded.
AnalysisAI
Memory exhaustion in quic-go's HTTP/3 implementation allows remote unauthenticated attackers to crash or degrade servers and clients by sending crafted QPACK-encoded HEADERS frames that exploit missing decoded size limits on HTTP trailer field sections. Affected versions (<= 0.59.0) enforce size caps only on the compressed HEADERS frame, not on the decoded output - a malicious peer can achieve roughly 50x expansion via QPACK static table entries, overwhelming available memory. No public exploit code has been identified at time of analysis, but the attack vector is network-accessible with no authentication required, making this a practical denial-of-service risk for any Go application using quic-go for HTTP/3.
Technical ContextAI
quic-go is the dominant Go implementation of the QUIC transport protocol and HTTP/3 (RFC 9114), identified by CPE pkg:go/github.com_quic-go_quic-go. HTTP/3 uses QPACK (RFC 9204) to compress field sections - both HTTP headers and trailers. The vulnerability (CWE-770: Allocation of Resources Without Limits or Throttling) exists in the parseTrailers function in http3/headers.go: http3.Server.MaxHeaderBytes (default 1 MB) and http3.Transport.MaxResponseHeaderBytes (default 10 MB) bounded only the compressed frame size, but the decoded http.Header map was built without any incremental size check. RFC 9114 section 4.2.2 mandates that implementations enforce decoded field section size limits via SETTINGS; quic-go honored this for request/response headers but not trailers. The expansion ratio of ~50x is achievable by referencing QPACK static table entries with long names and/or values, meaning a 1 MB compressed frame can yield ~50 MB of decoded header data before any limit triggers. This is structurally identical to CVE-2025-64702 (which targeted headers), with trailers as the newly identified attack surface. The fix in PR #5642 passes sizeLimit into parseTrailers, incrementally subtracts len(name) + len(value) + 32 per field per RFC 9114 section 4.2.2 overhead, and aborts the stream via errHeaderTooLarge when the budget is exhausted.
RemediationAI
Upgrade github.com/quic-go/quic-go to v0.59.1, which is the vendor-confirmed patched release. Run go get github.com/quic-go/quic-go@v0.59.1 and update go.sum accordingly. The fix is implemented in PR #5642 (https://github.com/quic-go/quic-go/pull/5642) and commit c56e8c79d1627cc1ed6005b421b4b0adadd83665. If immediate upgrade is not possible, a partial compensating control is to lower http3.Server.MaxHeaderBytes (server-side) or http3.Transport.MaxResponseHeaderBytes (client-side) to a small value (e.g., 64 KB), which reduces the compressed frame budget and indirectly constrains maximum decoded size - though it does not fully close the gap since the 50x expansion ratio still applies to the configured limit. Disabling HTTP trailers at the application layer (by not advertising or processing trailers) removes the attack surface entirely but may break standards-compliant clients or servers relying on trailer functionality. Placing quic-go servers behind a QUIC-aware reverse proxy that enforces RFC 9114 SETTINGS field section size limits would also mitigate the issue. Full vendor advisory is at https://github.com/quic-go/quic-go/security/advisories/GHSA-vvgj-x9jq-8cj9.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today