replace directive on quic-go shadows the fix for CVE-2025-59530

[lexfrei]

go.mod pins the QUIC stack to a fork based on quic-go v0.45:

require github.com/quic-go/quic-go v0.52.0
replace github.com/quic-go/quic-go => github.com/chungthuang/quic-go v0.45.1-0.20250428085412-43229ad201fd

The replace has no version on its left side, so it wins and the require line above it does nothing. That shadows every quic-go release since v0.45, including the fix for CVE-2025-59530 (7.5), which is patched in 0.49.1, 0.54.1 and 0.55.0. The pinned base is older than all three, so as far as I can tell no released cloudflared carries the fix.

It's a client-side crash. A server that sends HANDSHAKE_DONE before the handshake actually finishes makes the client drop Handshake keys before Initial keys, and the next undecryptable packet then trips the "no packets are queued after completion of the handshake" assert. cloudflared is the client here, so it takes something acting as the edge to hit it, but it's still a remote panic in the connection path.

I see the v0.59.1 bump landed twice and was reverted twice, both times shortly before a release:

• 68620ef landed 2026-06-12, reverted by 2bcaf09 on 2026-06-18 13:30. 2026.6.1 went out at 14:40.
• 02eb75b landed 2026-06-18 18:20, reverted by a53d9e5 on 2026-07-08 10:38. 2026.7.0 went out at 13:10.

Neither revert records a reason, so I won't guess at one. From outside the only visible thing is that v0.59 is a big move: the tracing and metrics code under quic/ is written against logging.PacketType and quic.Connection, and both moved.

If the blocker is the size of that move rather than the fix itself, the fix backports onto the current pin by itself. handleHandshakeConfirmed in the v0.45 fork is the same as today's upstream apart from the receiver name and the time type, so quic-go#5354 is seven lines:

diff --git a/connection.go b/connection.go
--- a/connection.go
+++ b/connection.go
@@ -851,6 +851,13 @@ func (s *connection) handleHandshakeComplete(now time.Time) error {
 }
 
 func (s *connection) handleHandshakeConfirmed(now time.Time) error {
+	// Drop initial keys.
+	// On the client side, this should have happened when sending the first Handshake packet,
+	// but this is not guaranteed if the server misbehaves.
+	// See CVE-2025-59530 for more details.
+	if err := s.dropEncryptionLevel(protocol.EncryptionInitial, now); err != nil {
+		return err
+	}
 	if err := s.dropEncryptionLevel(protocol.EncryptionHandshake, now); err != nil {
 		return err
 	}

Dropping Initial keys twice is safe on this base, which matters because the normal client path already dropped them by that point. sentPacketHandler.DropPackets returns early when the packet number space is already gone, DiscardInitialKeys is nil-safe, and cryptoStream.Finish only errors when the crypto stream still has unread data. Upstream relies on the same property, its own test asserts DiscardInitialKeys is called twice, and upstream's dropEncryptionLevel has no guard the v0.45 fork lacks.

I applied it to the pinned revision and built and tested a project that embeds the tunnel transport in-process. Build and the tunnel transport tests stay green. I could not run quic-go's own suite against it, a vendored copy has no test files, so that needs a run inside the fork.

I can open the PR against chungthuang/quic-go so the pin can move to a new revision of the same base, or you can just take the diff, it needs no attribution. This is meant as an interim step and the v0.59 upgrade still works whenever it's convenient, at which point this can be dropped.

[stareezy-1]

Root cause: the replace directive pins the QUIC stack to a fork based on quic-go v0.45, which predates the fix for CVE-2025-59530 (GHSA-47m2-4cr7-mhcw, 7.5): a server that sends HANDSHAKE_DONE before the handshake actually finishes makes the client drop Handshake keys before Initial keys, and the next undecryptable packet trips a panic in the connection path — a remote crash for cloudflared as the QUIC client.

The fix follows the backport path from the issue analysis: the fork pin is bumped to a commit that applies quic-go#5354 (drop initial keys when the handshake is confirmed) onto the exact previously-pinned fork state — the only source change is those 7 lines, avoiding the v0.59 API migration that was reverted twice. Companion fork PR: chungthuang/quic-go#16.

PR incoming.

[stareezy-1]

Update: the first PR (cloudflared#1712) was closed per maintainer review — the replace must stay anchored on the chungthuang/quic-go fork rather than a personal fork, so a bump via a personal fork is not acceptable. The backport itself is already prepared as chungthuang/quic-go#16; once that merges, the fix is a one-line bump of the existing pin to the new commit on the chungthuang fork.