CVE-2026-27145: 
Go vulnerability analysis and mitigation

CVE-2026-27145 is a Denial of Service vulnerability in the Go standard library's crypto/x509 package, specifically in the (*x509.Certificate).VerifyHostname method. The function called matchHostnames in a loop over all DNS Subject Alternative Name (SAN) entries, causing strings.Split(host, ".") to execute repeatedly on the same hostname, resulting in quadratic computational complexity. Affected versions are crypto/x509 before Go 1.25.11 and Go 1.26.0–1.26.3. It was published on June 2, 2026, with a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory, ENISA EUVD).

The root cause is an inefficient algorithm (CWE-407) in (*x509.Certificate).VerifyHostname, where hostname label splitting via strings.Split(host, ".") is performed redundantly inside a loop iterating over every DNS SAN entry in a certificate. Verification cost scales as O(n × m), where n is the number of DNS SAN entries and m is the number of labels in the hostname. Critically, x509.Verify performs hostname validation before building the certificate chain, meaning this expensive operation is triggered even for untrusted or attacker-controlled certificates presented during a TLS handshake. An attacker can craft a certificate with a very large DNS SAN list and a multi-label hostname to maximize CPU consumption on the verifying party (GitHub Advisory, Go Issue).

Successful exploitation causes excessive CPU consumption on any Go application that performs TLS certificate verification, potentially slowing or completely stalling TLS handshake operations. Because the vulnerability is triggered before chain validation, even certificates from untrusted sources can cause the denial of service, requiring no prior trust relationship. There is no confidentiality breach, but integrity impact is rated low and availability impact is rated high, meaning services relying on Go's TLS stack could become unresponsive under sustained attack (GitHub Advisory, ENISA EUVD).

No confirmed working exploit or proof-of-concept code is publicly available; a GitHub repository (HORKimhab/CVE-2026-27145) was identified but assessed as containing only boilerplate template files with no actual exploit code (Feedly). There is no evidence of in-the-wild exploitation, no threat actor attribution, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS score is approximately 0.011% (2nd percentile), indicating a very low probability of exploitation in the near term (GitHub Advisory).

1. Craft a malicious TLS certificate: Generate a self-signed X.509 certificate containing a very large number of DNS Subject Alternative Name (SAN) entries (e.g., thousands of unique DNS names).
2. Select a target: Identify a Go application that accepts and verifies TLS certificates from external parties (e.g., a TLS server that performs client certificate verification, or a client that connects to attacker-controlled servers).
3. Initiate a TLS handshake: Present the crafted certificate during the TLS handshake to the target Go application. No authentication or prior trust is required, as hostname verification occurs before chain building.
4. Trigger quadratic CPU consumption: The target's (*x509.Certificate).VerifyHostname iterates over all DNS SAN entries, repeatedly splitting the hostname string for each entry, consuming CPU proportional to (number of SANs × hostname label count).
5. Sustain the attack: Send repeated TLS connections with the malicious certificate to exhaust CPU resources, causing the target service to become slow or unresponsive (GitHub Advisory, Go Issue).

• Network: Unusually high volume of TLS handshake attempts from a single or small set of source IPs; TLS connections that stall or time out during the handshake phase.
• Process: Sustained high CPU utilization on Go application processes during periods of incoming TLS connections; CPU spikes correlated with TLS handshake activity rather than application logic.
• Logs: Application logs showing repeated TLS handshake failures or timeouts; Go runtime logs indicating prolonged certificate verification operations.
• Certificate Artifacts: Certificates presented during handshakes containing an abnormally large number of DNS SAN entries (hundreds to thousands), detectable via TLS inspection or logging of peer certificate details.

Upgrade to Go 1.25.11 or Go 1.26.4 (or later), which contain the fix that pre-computes the hostname label split outside the SAN iteration loop, reducing complexity to O(n + m) (Go CL 783621, GitHub Advisory). As a temporary measure, implement connection-level timeouts on TLS handshakes to limit the window of CPU exhaustion. Monitor for unusual CPU spikes during TLS handshake phases as an early warning signal. Downstream projects and distributions (SUSE, openSUSE, Red Hat, Chainguard, Wolfi, rclone, oauth2-proxy, etc.) have released updated packages incorporating the fix (SUSE Advisory, Red Hat Errata).

The Go team disclosed the vulnerability via the golang-announce mailing list and published a fix through the standard Go release process (golang-announce). Multiple Linux distributions including SUSE, openSUSE, and Red Hat issued security advisories and updated packages promptly after disclosure (SUSE Advisory, Red Hat Errata). Community discussion on platforms such as Mastodon (defcon.social) and security mailing lists (oss-sec) noted the algorithmic nature of the flaw. Downstream projects such as rclone and oauth2-proxy released updated versions incorporating the Go patch (rclone changelog, oauth2-proxy release).