fix(deps): update module github.com/quic-go/quic-go to v0.59.1 [security]#175
Open
renovate[bot] wants to merge 1 commit into
Open
fix(deps): update module github.com/quic-go/quic-go to v0.59.1 [security]#175renovate[bot] wants to merge 1 commit into
renovate[bot] wants to merge 1 commit into
Conversation
Contributor
Author
ℹ Artifact update noticeFile name: go.modIn order to perform the update(s) described in the table above, Renovate ran the
Details:
|
4bc014f to
196055b
Compare
196055b to
17421a7
Compare
17421a7 to
521838f
Compare
521838f to
daf97a2
Compare
daf97a2 to
570e01f
Compare
570e01f to
e55126f
Compare
e55126f to
599645d
Compare
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
599645d to
845f197
Compare
845f197 to
3c0cb8b
Compare
a1b8d05 to
85b6589
Compare
85b6589 to
06c0c15
Compare
Contributor
Author
ℹ️ Artifact update noticeFile name: go.modIn order to perform the update(s) described in the table above, Renovate ran the
Details:
|
06c0c15 to
b3d6ec9
Compare
b3d6ec9 to
e493ff6
Compare
e493ff6 to
085a3fe
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v0.35.1→v0.59.1quic-go's path validation mechanism can be exploited to cause denial of service
CVE-2023-49295 / GHSA-ppxx-5m9h-6vxf
More information
Details
An attacker can cause its peer to run out of memory sending a large number of PATH_CHALLENGE frames. The receiver is supposed to respond to each PATH_CHALLENGE frame with a PATH_RESPONSE frame. The attacker can prevent the receiver from sending out (the vast majority of) these PATH_RESPONSE frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate.
I published a more detailed description of the attack and its mitigation in this blog post: https://seemann.io/posts/2023-12-18-exploiting-quics-path-validation/
There's no way to mitigate this attack, please update quic-go to a version that contains the fix.
Severity
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
QUIC's Connection ID Mechanism vulnerable to Memory Exhaustion Attack
CVE-2024-22189 / GHSA-c33x-xqrf-c478
More information
Details
An attacker can cause its peer to run out of memory by sending a large number of NEW_CONNECTION_ID frames that retire old connection IDs. The receiver is supposed to respond to each retirement frame with a RETIRE_CONNECTION_ID frame. The attacker can prevent the receiver from sending out (the vast majority of) these RETIRE_CONNECTION_ID frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate.
I published a more detailed description of the attack and its mitigation in this blog post: https://seemann.io/posts/2024-03-19-exploiting-quics-connection-id-management/.
I also presented this attack in the IETF QUIC working group session at IETF 119: https://youtu.be/JqXtYcZAtIA?si=nJ31QKLBSTRXY35U&t=3683
There's no way to mitigate this attack, please update quic-go to a version that contains the fix.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
quic-go affected by an ICMP Packet Too Large Injection Attack on Linux
CVE-2024-53259 / GHSA-px8v-pp82-rcvr
More information
Details
Impact
An off-path attacker can inject an ICMP Packet Too Large packet. Since affected quic-go versions used
IP_PMTUDISC_DO, the kernel would then return a "message too large" error onsendmsg, i.e. when quic-go attempts to send a packet that exceeds the MTU claimed in that ICMP packet.By setting this value to smaller than 1200 bytes (the minimum MTU for QUIC), the attacker can disrupt a QUIC connection. Crucially, this can be done after completion of the handshake, thereby circumventing any TCP fallback that might be implemented on the application layer (for example, many browsers fall back to HTTP over TCP if they're unable to establish a QUIC connection).
As far as I understand, the kernel tracks the MTU per 4-tuple, so the attacker needs to at least know the client's IP and port tuple to mount an attack (assuming that it knows the server's IP and port).
Patches
The fix is easy: Use
IP_PMTUDISC_PROBEinstead ofIP_PMTUDISC_DO. This socket option only sets the DF bit, but disables the kernel's MTU tracking.Has the problem been patched? What versions should users upgrade to?
Fixed in https://github.com/quic-go/quic-go/pull/4729
Released in https://github.com/quic-go/quic-go/releases/tag/v0.48.2
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Use iptables to drop ICMP Unreachable packets.
References
Are there any links users can visit to find out more?
This bug was discovered while doing research for my new IETF draft on IP fragmentation: https://datatracker.ietf.org/doc/draft-seemann-tsvwg-udp-fragmentation/
Severity
CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
quic-go: Panic occurs when queuing undecryptable packets after handshake completion
CVE-2025-59530 / GHSA-47m2-4cr7-mhcw
More information
Details
Summary
A misbehaving or malicious server can trigger an assertion in a quic-go client (and crash the process) by sending a premature HANDSHAKE_DONE frame during the handshake.
Impact
A misbehaving or malicious server can cause a denial-of-service (DoS) attack on the quic-go client by triggering an assertion failure, leading to a process crash. This requires no authentication and can be exploited during the handshake phase. Observed in the wild with certain server implementations (e.g. Solana's Firedancer QUIC).
Affected Versions
Users are recommended to upgrade to the latest patched version in their respective maintenance branch or to v0.55.0 or later.
Details
For a regular 1-RTT handshake, QUIC uses three sets of keys to encrypt / decrypt QUIC packets:
On the client side, Initial keys are discarded when the first Handshake packet is sent. Handshake keys are discarded when the server's HANDSHAKE_DONE frame is received, as specified in section 4.9.2 of RFC 9001. Crucially, Initial keys are always dropped before Handshake keys in a standard handshake.
Due to packet reordering, it is possible to receive a packet with a higher encryption level before the key for that encryption level has been derived. For example, the server's Handshake packets (containing, among others, the TLS certificate) might arrive before the server's Initial packet (which contains the TLS ServerHello). In that case, the client queues the Handshake packets and decrypts them as soon as it has processed the ServerHello and derived Handshake keys.
After completion of the handshake, Initial and Handshake packets are not needed anymore and will be dropped. quic-go implements an assertion that no packets are queued after completion of the handshake.
A misbehaving or malicious server can trigger this assertion, and thereby cause a panic, by sending a HANDSHAKE_DONE frame before actually completing the handshake. In that case, Handshake keys would be dropped before Initial keys.
This can only happen if the server implementation is misbehaving: the server can only complete the handshake after receiving the client's TLS Finished message (which is sent in Handshake packets).
The Fix
quic-go needs to be able to handle misbehaving server implementations, including those that prematurely send a HANDSHAKE_DONE frame. We now discard Initial keys when receiving a HANDSHAKE_DONE frame, thereby correctly handling premature HANDSHAKE_DONE frames. The fix was implemented in https://github.com/quic-go/quic-go/pull/5354.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
quic-go HTTP/3 QPACK Header Expansion DoS
CVE-2025-64702 / GHSA-g754-hx8w-x2g6
More information
Details
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 header field section (many unique header names and/or large values). The implementation builds an
http.Header(used on thehttp.Requestandhttp.Response, respectively), while only enforcing limits on the size of the (QPACK-compressed) HEADERS frame, but not on the decoded header, leading to memory exhaustion.Impact
A misbehaving or malicious peer can cause a denial-of-service (DoS) attack on quic-go's HTTP/3 servers or clients by triggering excessive memory allocation, potentially leading to crashes or exhaustion. It affects both servers and clients due to symmetric header construction.
Details
In HTTP/3, headers are compressed using QPACK (RFC 9204). quic-go's HTTP/3 server (and client) decodes the QPACK-encoded HEADERS frame into header fields, then constructs an http.Request (or response).
http3.Server.MaxHeaderBytesandhttp3.Transport.MaxResponseHeaderBytes, respectively, limit encoded HEADERS frame size (default: 1 MB server, 10 MB client), but not decoded size. A maliciously crafted HEADERS frame can expand to ~50x the encoded size using QPACK static table entries with long names / values.RFC 9114 requires enforcing decoded field section size limits via SETTINGS, which quic-go did not do.
The Fix
quic-go now enforces RFC 9114 decoded field section size limits, sending SETTINGS_MAX_FIELD_SECTION_SIZE and using incremental QPACK decoding to check the header size after each entry, aborting early on violations with HTTP 431 (on the server side) and stream reset (on the client side).
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
quic-go: HTTP/3 QPACK Trailer Expansion Memory Exhaustion
CVE-2026-40898 / GHSA-vvgj-x9jq-8cj9
More information
Details
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.Headerfor the correspondinghttp.Requestorhttp.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.Requestorhttp.Response.http3.Server.MaxHeaderBytesandhttp3.Transport.MaxResponseHeaderByteslimit 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.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
quic-go/quic-go (github.com/quic-go/quic-go)
v0.59.1Compare Source
This patch release backports #5642, which adds validation for HTTP/3 trailers.
v0.59.0Compare Source
This release adds a couple of new features:
ReceiveStreamandStream: #5501Breaking Changes
ClientHelloInfo: #5497ConnectionTracingIDandConnectionTracingKey: #5521ConnectionStatenow reports both the local and the remote status of the QUIC Datagram and Reliable Stream Reset extensions: #5533Other Notable Fixes
RecordEventandClose: #5523Changelog
Full Changelog: quic-go/quic-go@v0.58.0...v0.59.0
v0.58.1Compare Source
This patch release backports fixes for a bug in the PTO queueing logic that could lead to an infinite loop of PING packets.
Bug Fixes
v0.58.0Compare Source
This release optimizes the QUIC handshake:
Other notable changes
datagram_idonpacket_sent,packet_receivedandpacket_bufferedevents, using the CRC32 of the packet: #5455Changelog
Full Changelog: quic-go/quic-go@v0.57.0...v0.58.0
v0.57.1Compare Source
This release resolves a panic during the server handshake when using the upcoming Go 1.26 toolchain, specifically occurring with TLS session tickets disabled (#5462). This issue does not impact builds on Go 1.25 or earlier versions.
v0.57.0Compare Source
This release contains a fix for CVE-2025-64702 by reworking the HTTP/3 header processing logic:
Breaking Changes
Transport.MaxResponseBytesis now anint(before:int64): #5433Notable Fixes
What's Changed
New Contributors
Full Changelog: quic-go/quic-go@v0.56.0...v0.57.0
v0.56.0Compare Source
This release introduces qlog support for HTTP/3 (#5367, #5372, #5374, #5375, #5376, #5381, #5383).
For this, we completely changed how connection tracing works. Instead of a general-purpose
logging.ConnectionTracer(which we removed entirely), we now have a qlog-specific tracer (#5356, #5417). quic-go users can now implement their own qlog events.It also removes the Prometheus-based metrics collection. Please comment on the tracking issue (#5294) if you rely on metrics and are interested in seeing metrics brought back in a future release.
Notable Changes
Behind the Scenes
Go 1.25 introduced support for testing concurrent code using
testing/synctest. We've been working on transitioning tests to use synctest (#5357, #5391, #5393, #5397, #5398, #5403, #5414, #5415), using @MarcoPolo's simnet package to simulate a network in memory.Using synctest makes test execution more reliable (reducing flakiness). The use of a synthetic clock leads to a massive speedup; the execution time of some integration tests was reduced from 20s to less than 1ms. The work will continue for the next release (see tracking issue: #5386).
Changelog
New Contributors
Full Changelog: quic-go/quic-go@v0.55.0...v0.56.0
v0.55.0Compare Source
This release contains a number of improvements and fixes, and it updates the supported Go versions to 1.24 and 1.25.
Optimizations
When sending packets on a QUIC connection, RFC 9002 requires us to save the timestamp for every packet sent. In #5344, we implemented a memory-optimized drop-in replacement for
time.Time, which reduces the memory required from 24 to 8 bytes, and vastly speeds up timer calculations (which happen very frequently).New Features
Conn.ConnectionStats, thanks to @MarcoPoloNotable Fixes
Transport: #5324, thanks to @GloneeTransport.Roundtripcalls: #5323, thanks to @GloneeBehind the Scenes
We have started transitioning tests to make use of the new
synctestpackage that was added in Go 1.25 (and was available as aGOEXPERIMENTin Go 1.24): #5291, #5296, #5298, #5299, #5302, #5304, #5305, #5306, #5317. This is a lot of work, but it makes the test execution both faster and more reliable.Changelog
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.