You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
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
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
All versions prior to v0.49.1 (for the 0.49 branch)
Versions v0.50.0 to v0.54.0 (inclusive)
Fixed in v0.49.1, v0.54.1, and v0.55.0 onward
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:
Initial keys (derived from a static key and the connection ID)
Handshake keys (derived from the client's and server's key shares in the TLS handshake)
1-RTT keys (derived when the TLS handshake finishes)
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 anassertion 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 inhttps://github.com/quic-go/quic-go/pull/5354.
quic-go: Panic occurs when queuing undecryptable packets after handshake completion
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
All versions prior to v0.49.1 (for the 0.49 branch)
Versions v0.50.0 to v0.54.0 (inclusive)
Fixed in v0.49.1, v0.54.1, and v0.55.0 onward
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:
Initial keys (derived from a static key and the connection ID)
Handshake keys (derived from the client's and server's key shares in the TLS handshake)
1-RTT keys (derived when the TLS handshake finishes)
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 anassertion 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 inhttps://github.com/quic-go/quic-go/pull/5354.
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 anhttp.Header (used on thehttp.Request andhttp.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.MaxHeaderBytes andhttp3.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).
This release reworks the HTTP/3 header processing logic:
Both client and server now send their respective header size constraints using the SETTINGS_MAX_FIELD_SECTION_SIZE setting:#5431
For any QPACK-related errors, the correct error code (QPACK_DECOMPRESSION_FAILED) is now used:#5439
QPACK header parsing is now incremental (instead of parsing all headers at once), which is ~5-10% faster and reduces allocations:#5435 (andquic-go/qpack#67)
The server now sends a 431 status code (Request Header Fields Too Large) when encountering HTTP header fields exceeding the size constraint:#5452
Breaking Changes
http3:Transport.MaxResponseBytes is now anint (before:int64):#5433
Notable Fixes
qlogwriter: fix storing of event schemas (this prevented qlog event logging from working for HTTP/3):#5430
http3: errors sending the request are now ignored, instead, the response from the server is read (thereby allowing the client to read the status code, for example):#5432
What's Changed
build(deps): bump golangci/golangci-lint-action from 8 to 9 by@dependabot[bot] in#5426
For this, we completely changed how connection tracing works. Instead of a general-purposelogging.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
replaced the unmaintained gojay with a custom, performance-optimized JSON encoder (#5353,#5371)
quicvarint: improved panic message for numbers larger than 2^62 (#5410)
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).
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 fortime.Time, which reduces the memory required from 24 to 8 bytes, and vastly speeds up timer calculations (which happen very frequently).
New Features
Basic connection statistics are now exposed viaConn.ConnectionStats, thanks to@MarcoPolo
On some links, packet reordering can lead to spurious detections of packet loss when using the loss detection logic specified in RFC 9002.#5355 adds logic detect when packet loss is detected spuriously.
Notable Fixes
http3: don't allow usage of closedTransport:#5324, thanks to@Glonee
http3: fix race in concurrentTransport.Roundtrip calls:#5323, thanks to@Glonee
improve and fix connection timer logic:#5339, thanks to@sukunrt for a very comprehensive code review
Behind the Scenes
We have started transitioning tests to make use of the newsynctest package that was added in Go 1.25 (and was available as aGOEXPERIMENT in 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
wire: implement parsing and writing of the ACK_FREQUENCY frame by@marten-seemann in#5264
wire: implement parsing and writing of the IMMEDIATE_ACK frame by@marten-seemann in#5265
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.
Uh oh!
There was an error while loading.Please reload this page.
This PR contains the following updates:
v0.54.0->v0.57.0Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
GitHub Vulnerability Alerts
CVE-2025-59530
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 anassertion 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 inhttps://github.com/quic-go/quic-go/pull/5354.
quic-go: Panic occurs when queuing undecryptable packets after handshake completion
CVE-2025-59530 /GHSA-47m2-4cr7-mhcw /GO-2025-4017
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 anassertion 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 inhttps://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 byOSV and theGitHub Advisory Database (CC-BY 4.0).
Panic occurs when queuing undecryptable packets after handshake completion in github.com/quic-go/quic-go
CVE-2025-59530 /GHSA-47m2-4cr7-mhcw /GO-2025-4017
More information
Details
Panic occurs when queuing undecryptable packets after handshake completion in github.com/quic-go/quic-go
Severity
Unknown
References
This data is provided byOSV and theGo Vulnerability Database (CC-BY 4.0).
quic-go HTTP/3 QPACK Header Expansion DoS
CVE-2025-64702 /GHSA-g754-hx8w-x2g6 /GO-2025-4233
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 byOSV and theGitHub Advisory Database (CC-BY 4.0).
HTTP/3 QPACK Header Expansion DoS in github.com/quic-go/quic-go
CVE-2025-64702 /GHSA-g754-hx8w-x2g6 /GO-2025-4233
More information
Details
HTTP/3 QPACK Header Expansion DoS in github.com/quic-go/quic-go
Severity
Unknown
References
This data is provided byOSV and theGo Vulnerability Database (CC-BY 4.0).
Release Notes
quic-go/quic-go (github.com/quic-go/quic-go)
v0.57.0Compare Source
This release reworks 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.25introduced 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
interface{}withanyby@marten-seemann in#5290go mod tidy -diffto check for tidiedgo.modby@marten-seemann in#5303New Contributors
Full Changelog:quic-go/quic-go@v0.54.0...v0.55.0
v0.54.1Compare Source
Configuration
📅Schedule: Branch creation - "" in timezone UTC, Automerge - At any time (no schedule defined).
🚦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 byMend Renovate. View therepository job log.