CVE-2025-68121 is a maximum severity flaw (CVSS 10.0) in Go's crypto/tls package. If ClientCAs or RootCAs change between a first handshake and a resumed one, the resumed handshake may succeed when it should fail. Update Go to the patched release named in the Go announcement.
What's affected
- The Go standard library package crypto/tls.
- Fixed versions: not listed in the record. See the golang-announce post and the Go vulnerability entry GO-2026-4337 for the patched releases.
- Programs that clone a tls.Config and change ClientCAs or RootCAs, or that use GetConfigForClient to return different configs.
How to check if you're exposed
Check the Go version used to build each binary:
go version
go version -m ./yourbinary
The second command reads the toolchain from a compiled program, which matters because the standard library is compiled in. Then run the Go vulnerability scanner against your code:
govulncheck ./...
It reports whether your code calls the affected function, which is the right first filter for a standard library issue. Search your code for Config.Clone, GetConfigForClient, ClientCAs and RootCAs.
What to do now
- List the Go versions your services are built with, including base images and CI toolchains.
- Upgrade to the patched Go release listed in the Go announcement and rebuild every affected binary.
- Run govulncheck to confirm whether your call paths reach the issue.
- If you cannot rebuild yet, review code that changes trust settings per connection and consider disabling session resumption for those configurations.
- Redeploy and verify with
go version -mon the shipped binary.
Why it matters
The weakness is CWE-295, improper certificate validation. TLS session resumption lets a client and server skip a full handshake by reusing earlier state. The trust decision made in the first handshake is supposed to hold, or be redone, when the session is resumed.
Here, the resumed handshake did not account for a changed set of trusted certificate authorities. A client could resume a session with a server it would not have trusted under the new settings, or a server could resume with a client it would have rejected.
Because the flaw sits in the standard library, patching means rebuilding every Go program, not updating one dependency. That is why an inventory of what each binary was built with is the useful first step. The record does not list this CVE as exploited in the wild.
Standard library flaws are a different shape of work from library flaws. There is no single package to bump. The fix reaches production only when each service is rebuilt with a patched toolchain and redeployed.
Three things speed that up. Keep the Go version in one place per repository, such as the go directive and a CI variable. Build base images on a schedule, so that they pick up the newest patch release. And store the output of go version -m for shipped binaries, so that you can answer which services use which toolchain.
Reachability analysis is helpful here. A Go program that never sets different trust pools on cloned configs, and never returns different configs per connection, is less exposed than one that does. That is not a reason to skip the update, but it helps you decide what goes first.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why must I rebuild binaries for CVE-2025-68121?
crypto/tls is compiled into each Go program, so a new Go release only protects binaries built with it.
Sources
Last reviewed: 19 October 2026.
