CVE-2025-68121: 
Go vulnerability analysis and mitigation

CVE-2025-68121 is an improper certificate validation vulnerability in Go's crypto/tls package that allows TLS session resumption to succeed when it should fail. During session resumption, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may bypass certificate validation checks. This affects Go versions before 1.24.13, 1.25.x before 1.25.7, and 1.26.0-rc1/rc2. It was published on February 5, 2026, and carries a CVSS v3.1 base score of 10.0 (Critical) as scored by Feedly, though Oracle's Solaris bulletin scores it at 7.4–8.6 depending on context (Go Vuln DB, IBM Advisory, Oracle CPU Apr 2026).

The root cause is classified as CWE-295 (Improper Certificate Validation). The flaw occurs in Go's crypto/tls session resumption logic: when a Config object is cloned via Config.Clone() and the returned config's ClientCAs or RootCAs fields are subsequently mutated, or when Config.GetConfigForClient is used to return a dynamically modified config, the resumed TLS handshake uses stale or inconsistent CA state. As a result, a client may resume a session with a server it would not have accepted during the initial handshake, or a server may resume a session with a client that would have been rejected. The attack vector is network-based and requires no privileges or user interaction, but the mutation of CA fields between handshakes is a precondition (Go Issue, Go CL, Go Vuln DB).

Successful exploitation allows an unauthenticated network attacker to establish TLS sessions that bypass certificate authority validation, effectively achieving an authentication bypass. This can enable unauthorized communication with systems that should have rejected the connection based on updated certificate requirements, potentially exposing sensitive data in transit, undermining mutual TLS authentication, and allowing lateral movement within environments relying on certificate-based access controls. The vulnerability affects any Go application using crypto/tls with dynamic CA configuration via Config.Clone() with subsequent mutation or Config.GetConfigForClient (Go Vuln DB, IBM Advisory).

A proof-of-concept is referenced via the Go issue tracker at go.dev/issue/77217, but there is no evidence of active in-the-wild exploitation at this time. The EPSS score is approximately 0.007% (0.000070), indicating low current exploitation probability. The vulnerability is not listed in the CISA KEV catalog. No specific threat actor attribution has been reported. Patches are available and widely distributed across multiple downstream products including IBM (Instana, watsonx Orchestrate, API Connect, Guardium, Db2), Oracle (Solaris), Red Hat, SUSE, Amazon Linux, and others (Go Issue, IBM Advisory, Oracle CPU Apr 2026).

1. Identify target: Locate Go-based services (e.g., gRPC servers, HTTPS APIs, mutual TLS endpoints) that use crypto/tls with dynamic CA configuration via Config.Clone() with subsequent mutation or Config.GetConfigForClient callbacks.
2. Establish initial TLS session: Connect to the target service and complete a valid initial TLS handshake, establishing a session ticket or session ID for resumption.
3. Trigger CA mutation window: Exploit the timing window during which the server or client mutates ClientCAs/RootCAs between the initial handshake and a subsequent session resumption attempt (e.g., during a certificate rotation or policy update event).
4. Attempt session resumption: Reconnect to the target using the previously obtained session ticket, triggering the TLS session resumption path in crypto/tls.
5. Bypass certificate validation: Due to the stale CA state used during resumption, the handshake succeeds even though the current CA configuration would have rejected it, granting unauthorized access to the service (Go Issue, Go Vuln DB).

• Network: Unexpected TLS session resumptions from clients or to servers that were recently removed from trusted CA lists; TLS connections succeeding after certificate authority rotation events without full re-authentication.
• Logs: Application logs showing successful TLS handshakes (resumed sessions) from endpoints that should have been rejected following a CA configuration change; absence of full handshake logs where resumption was expected to fail.
• Application Behavior: Go services accepting connections from clients with certificates issued by CAs that were removed from ClientCAs after the initial handshake; clients successfully connecting to servers whose certificates are no longer trusted under the updated RootCAs.
• Configuration Events: Concurrent CA rotation or Config.Clone() usage with field mutation in Go TLS code paths, particularly in services using GetConfigForClient for per-client configuration (Go Issue).

Upgrade Go to the following fixed versions: 1.24.13 (for 1.24.x branch), 1.25.7 (for 1.25.x branch), or 1.26.0 or later (for 1.26.x branch). As a workaround, avoid mutating ClientCAs or RootCAs fields in Config objects between handshakes; if dynamic CA configuration is required, implement proper locking or use separate Config instances per connection rather than mutating cloned configs. Apply vendor-specific patches from IBM (Instana, watsonx Orchestrate, API Connect, Db2, Guardium), Oracle (Solaris, CPU April 2026), Red Hat, SUSE, and other affected distributions. Review and audit any code using Config.Clone() with subsequent field mutations or Config.GetConfigForClient callbacks (Go CL, Go Vuln DB, IBM Advisory, Oracle CPU Apr 2026).

The Go team disclosed the vulnerability via the golang-announce mailing list and the Go vulnerability database (GO-2026-4337). Multiple security news outlets including GBHackers, CyberPress, and CyberSecurityNews covered the Go 1.25.7/1.24.13 patch releases that addressed this and related vulnerabilities. The Portainer team published a dedicated blog post discussing CVE-2025-68121's impact on Docker-related tooling. Field Effect published a technical write-up on TLS authentication bypass in VMware Tanzu Valkey related to this CVE. The vulnerability received broad downstream attention given Go's widespread use in cloud-native infrastructure, with patches rapidly propagated to Traefik, CoreDNS, Istio, Grafana, rclone, and many other projects (Portainer Blog, Field Effect).