CVE-2026-27145: x509.Certificate DoS Vulnerability

CVE-2026-27145 Overview

CVE-2026-27145 is an algorithmic complexity vulnerability in the Go standard library's crypto/x509 package. The flaw resides in (*x509.Certificate).VerifyHostname, which previously invoked matchHostnames inside a loop iterating over every DNS Subject Alternative Name (SAN) entry. Each iteration repeatedly executed strings.Split(host, ".") against the same input hostname. Verification cost scaled quadratically based on the number of SAN entries multiplied by the hostname's label count. Because x509.Verify validates hostnames before building the certificate chain, the overhead occurs even when processing untrusted certificates. An attacker presenting a certificate with a large DNS SAN list can force excessive CPU consumption on the verifier.

Critical Impact
Attacker-supplied certificates with large DNS SAN lists can trigger quadratic CPU consumption during hostname verification, enabling denial-of-service against Go-based TLS clients and servers.

Affected Products

Go standard library crypto/x509 package
Applications using (*x509.Certificate).VerifyHostname for TLS peer validation
Tracked upstream as GO-2026-5037

Discovery Timeline

2026-06-02 - CVE-2026-27145 published to NVD
2026-06-02 - Last updated in NVD database

Technical Details for CVE-2026-27145

Vulnerability Analysis

The defect is an algorithmic complexity issue [CWE-407] in the hostname verification path of Go's TLS certificate handling. VerifyHostname walks the DNS SAN list and calls matchHostnames for each entry. Within that path, the implementation re-splits the candidate hostname on the . character on every iteration. The split allocates a new slice and traverses the full hostname string. Cost therefore grows as O(N × L) where N is the SAN count and L is the label count of the hostname under verification. With thousands of SAN entries the verifier spends measurable CPU time on hostname matching alone.

The issue is amplified by the order of operations inside x509.Verify. Hostname validation runs before chain building, so the verifier processes attacker-controlled SAN data even when the presented certificate is untrusted. A remote party that controls the certificate sent during a TLS handshake can therefore trigger the slow path without holding a valid chain to a trusted root.

Root Cause

The root cause is redundant work inside a hot loop. The hostname is constant across all SAN comparisons, yet strings.Split on the hostname executes on every iteration instead of once before the loop. The fix hoists the split out of the loop so that label decomposition is performed a single time per verification call.

Attack Vector

The attacker delivers a certificate containing a large DNS SAN list to any Go process that calls VerifyHostname either directly or transitively through the standard crypto/tls handshake. A malicious TLS server can target Go-based clients, and a malicious TLS client can target Go-based servers that perform mutual TLS. Repeated handshake attempts compound CPU usage and can degrade availability of the affected service. The vulnerability requires no authentication and no special privilege beyond the ability to complete a partial TLS handshake.

A technical description of the change is available in the Go.dev Code Change and the Go.dev Issue Report.

Detection Methods for CVE-2026-27145

Indicators of Compromise

TLS handshakes where the peer certificate contains an unusually large DNS SAN list, often numbering in the thousands.
Sustained CPU spikes in Go-based services correlated with inbound or outbound TLS handshake activity.
Repeated short-lived TLS connections from a single source that never complete application-layer requests.

Detection Strategies

Inspect TLS handshake telemetry for certificates whose SAN count exceeds operational baselines for your environment.
Compare Go runtime profiling data against historical baselines to identify time spent in crypto/x509 hostname verification.
Correlate process-level CPU saturation events with TLS connection logs to spot handshake-driven exhaustion.

Monitoring Recommendations

Enable structured TLS logging on reverse proxies and load balancers that front Go services, including SAN counts where supported.
Alert on anomalous handshake durations on listeners served by Go binaries.
Track the Go runtime version of deployed services so that unpatched binaries are visible to vulnerability management.

How to Mitigate CVE-2026-27145

Immediate Actions Required

Identify all Go-built binaries in your environment and record their compiled Go toolchain version.
Prioritize internet-facing services that terminate or initiate TLS handshakes using the standard library.
Rebuild affected applications with a patched Go toolchain and redeploy.

Patch Information

The fix moves the hostname label split outside the SAN matching loop. Refer to the Go.dev Vulnerability Advisory and the GoLang Announce Post for the specific Go releases that contain the corrected VerifyHostname implementation. Rebuilding the application with a fixed toolchain is required because crypto/x509 is part of the standard library and is statically linked into Go binaries.

Workarounds

Place a non-Go TLS terminator in front of Go services to filter or reject certificates with abnormally large SAN lists.
Apply per-source connection rate limits to reduce the volume of handshakes any single peer can initiate.
Where mutual TLS is not required, disable client certificate verification on Go servers until the toolchain is upgraded.

bash

# Verify the Go toolchain version used to build a binary
go version -m /path/to/binary

# Identify modules and standard library version embedded in the binary
govulncheck /path/to/binary