Skip to content

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
masterfrom
renovate/go-github.com-quic-go-quic-go-vulnerability
Open

fix(deps): update module github.com/quic-go/quic-go to v0.59.1 [security]#175
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/go-github.com-quic-go-quic-go-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Aug 6, 2024

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
github.com/quic-go/quic-go v0.35.1v0.59.1 age confidence

quic-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 Score: 6.4 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H

References

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 Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

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 on sendmsg, 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_PROBE instead of IP_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 Score: 6.0 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

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
  • 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 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 Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

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 the http.Request and http.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 and http3.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 Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

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.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.

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

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.1

Compare Source

This patch release backports #​5642, which adds validation for HTTP/3 trailers.

v0.59.0

Compare Source

This release adds a couple of new features:

  • Adds an API to peek stream data on ReceiveStream and Stream: #​5501
  • Adds an API to peek the next varint on a stream: #​5502
  • Reworks the API exposed by the HTTP/3 package for WebTransport: #​5509, #​5512. Regular HTTP/3 use cases should not be affected by these changes.
  • Adds support for HTTP request trailers (trailers sent by the client): #​5507

Breaking Changes

  • Removes the deprecated ClientHelloInfo: #​5497
  • Removes the deprecated ConnectionTracingID and ConnectionTracingKey: #​5521
  • http3: the qlogger is now closed after all streams have been handled: #​5524
  • The ConnectionState now reports both the local and the remote status of the QUIC Datagram and Reliable Stream Reset extensions: #​5533

Other Notable Fixes

  • Fixes an infinite loop of PING-only packets caused by a bug in the PTO queueing logic: #​5538 and #​5539
  • http3: Fixes a race condition between new request streams and GOAWAY: #​5522
  • qlog: Fixes a race condition between RecordEvent and Close: #​5523

Changelog

Full Changelog: quic-go/quic-go@v0.58.0...v0.59.0

v0.58.1

Compare 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

  • ackhandler: fix qlogging of outstanding packet count (#​5538)
  • ackhandler: fix counting of packets queued for PTO probing (#​5539)

v0.58.0

Compare Source

This release optimizes the QUIC handshake:

  • Multiple incoming packets are now processed before sending an acknowledgment, reducing the total number of packets sent: #​5451
  • ACK frames are now packed into coalesced packets, reducing the need to send a separate packet just for the ACK in many cases: #​5477
  • When packets are buffered during the handshake, this now doesn't lead to inflated RTT measurements anymore: #​5493, #​5494

Other notable changes

  • quic-go now has a new logo: #​5484
  • ACK frames can now be encoded with up to 64 ranges (previously: 32): #​5476
  • Serializing ACK frames is now significantly faster: #​5476
  • Improved batch packet processing logic: #​5478
  • qlog: added support for the datagram_id on packet_sent, packet_received and packet_buffered events, using the CRC32 of the packet: #​5455

Changelog

Full Changelog: quic-go/quic-go@v0.57.0...v0.58.0

v0.57.1

Compare 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.0

Compare Source

This release contains a fix for CVE-2025-64702 by reworking 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 (and quic-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 an int (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

New Contributors

Full Changelog: quic-go/quic-go@v0.56.0...v0.57.0

v0.56.0

Compare 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

  • replaced the unmaintained gojay with a custom, performance-optimized JSON encoder (#​5353, #​5371)
  • quicvarint: improved panic message for numbers larger than 2^62 (#​5410)

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.0

Compare 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

  • Basic connection statistics are now exposed via Conn.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 closed Transport: #​5324, thanks to @​Glonee
  • http3: fix race in concurrent Transport.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 new synctest package that was added in Go 1.25 (and was available as a GOEXPERIMENT 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

Note

PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • 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.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate

renovate Bot commented Aug 6, 2024

Copy link
Copy Markdown
Contributor Author

ℹ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

  • 4 additional dependencies were updated
  • The go directive was updated for compatibility reasons

Details:

Package Change
go 1.20 -> 1.22
golang.org/x/net v0.11.0 -> v0.28.0
golang.org/x/crypto v0.10.0 -> v0.26.0
golang.org/x/exp v0.0.0-20230522175609-2e198f4a06a1 -> v0.0.0-20240506185415-9bf2ced13842
golang.org/x/mod v0.11.0 -> v0.18.0

@renovate renovate Bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 4bc014f to 196055b Compare September 11, 2024 17:29
@renovate renovate Bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 196055b to 17421a7 Compare November 17, 2024 15:36
@renovate renovate Bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 17421a7 to 521838f Compare December 2, 2024 19:52
@renovate renovate Bot changed the title fix(deps): update module github.com/quic-go/quic-go to v0.42.0 [security] fix(deps): update module github.com/quic-go/quic-go to v0.48.2 [security] Dec 2, 2024
@renovate renovate Bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 521838f to daf97a2 Compare December 22, 2024 18:48
@renovate renovate Bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from daf97a2 to 570e01f Compare March 3, 2025 13:17
@renovate renovate Bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 570e01f to e55126f Compare March 11, 2025 09:25
@renovate renovate Bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from e55126f to 599645d Compare April 8, 2025 16:06
@socket-security

socket-security Bot commented Apr 8, 2025

Copy link
Copy Markdown

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security
Vulnerability Quality Maintenance License
Updatedgithub.com/​quic-go/​quic-go@​v0.35.1 ⏵ v0.59.174 +1100 +27100100100
Updatedgolang.org/​x/​net@​v0.11.0 ⏵ v0.43.075 +199 +27100100100

View full report

@renovate renovate Bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 599645d to 845f197 Compare May 7, 2025 10:49
@renovate renovate Bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 845f197 to 3c0cb8b Compare August 10, 2025 14:35
@renovate renovate Bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch 2 times, most recently from a1b8d05 to 85b6589 Compare October 10, 2025 20:50
@renovate renovate Bot changed the title fix(deps): update module github.com/quic-go/quic-go to v0.48.2 [security] fix(deps): update module github.com/quic-go/quic-go to v0.49.1 [security] Oct 10, 2025
@renovate renovate Bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 85b6589 to 06c0c15 Compare December 11, 2025 22:25
@renovate renovate Bot changed the title fix(deps): update module github.com/quic-go/quic-go to v0.49.1 [security] fix(deps): update module github.com/quic-go/quic-go to v0.57.0 [security] Dec 11, 2025
@renovate

renovate Bot commented Dec 11, 2025

Copy link
Copy Markdown
Contributor Author

ℹ️ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

  • 2 additional dependencies were updated
  • The go directive was updated for compatibility reasons

Details:

Package Change
go 1.20 -> 1.24
golang.org/x/net v0.11.0 -> v0.43.0
golang.org/x/crypto v0.10.0 -> v0.41.0

@renovate renovate Bot changed the title fix(deps): update module github.com/quic-go/quic-go to v0.57.0 [security] fix(deps): update module github.com/quic-go/quic-go to v0.57.0 [security] - autoclosed Mar 27, 2026
@renovate renovate Bot closed this Mar 27, 2026
@renovate renovate Bot deleted the renovate/go-github.com-quic-go-quic-go-vulnerability branch March 27, 2026 02:03
@renovate renovate Bot changed the title fix(deps): update module github.com/quic-go/quic-go to v0.57.0 [security] - autoclosed fix(deps): update module github.com/quic-go/quic-go to v0.57.0 [security] Mar 30, 2026
@renovate renovate Bot reopened this Mar 30, 2026
@renovate renovate Bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from 06c0c15 to b3d6ec9 Compare March 30, 2026 21:03
@renovate renovate Bot changed the title fix(deps): update module github.com/quic-go/quic-go to v0.57.0 [security] fix(deps): update module github.com/quic-go/quic-go to v0.57.0 [security] - autoclosed Apr 27, 2026
@renovate renovate Bot closed this Apr 27, 2026
@renovate renovate Bot changed the title fix(deps): update module github.com/quic-go/quic-go to v0.57.0 [security] - autoclosed fix(deps): update module github.com/quic-go/quic-go to v0.57.0 [security] Apr 27, 2026
@renovate renovate Bot reopened this Apr 27, 2026
@renovate renovate Bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from b3d6ec9 to e493ff6 Compare April 27, 2026 20:58
@renovate renovate Bot force-pushed the renovate/go-github.com-quic-go-quic-go-vulnerability branch from e493ff6 to 085a3fe Compare June 3, 2026 23:52
@renovate renovate Bot changed the title fix(deps): update module github.com/quic-go/quic-go to v0.57.0 [security] fix(deps): update module github.com/quic-go/quic-go to v0.59.1 [security] Jun 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants