CVE-2025-61729

What it actually does

A vulnerability exists in the Go language's `HostnameError.Error()` function. When constructing an error string for a certificate with numerous hostnames, the function uses an inefficient string concatenation process with quadratic runtime complexity and no limit on the number of hosts included. This allows a malicious actor to trigger excessive CPU and memory consumption by providing a specially crafted certificate, leading to a denial of service (DoS).

Why it matters to the business

An attacker can render services built with vulnerable versions of Go unresponsive or cause them to crash by sending a malicious digital certificate. This can lead to service outages for customers and partners, disrupting business operations, and potentially causing financial or reputational damage. The high CVSS score of 7.5 underscores the significant risk of service unavailability.

How an attack unfolds

An attacker targets a public-facing service, such as a web server with mutual TLS (mTLS) authentication, that is built using a vulnerable version of Go. The attacker crafts a malicious X.509 certificate containing an exceptionally large number of hostnames in fields like the Subject Alternative Name (SAN). They then initiate a TLS handshake with the target service and present this certificate. When the Go application's validation logic fails and calls the `HostnameError.Error()` function to report the mismatch, the function enters a resource-intensive loop to build a massive error string. This exhausts CPU and memory resources, causing the application to hang or crash, effectively denying service to legitimate users.

How to fix it

To remediate this vulnerability, developers must upgrade their Go development environment to a version that includes the patch and recompile their applications. The specific fix was introduced in commit `1296453960bac0fb5675853c40e3747e5237e16e`. Check the official Go release notes for the first stable version that includes this commit and upgrade your toolchain accordingly before rebuilding and deploying your Go services.

How to confirm the fix worked

To validate the fix, confirm that all Go applications have been rebuilt using a patched version of the Go toolchain. You can verify the toolchain version used to build a binary by running `go version -m <path_to_binary>`. Additionally, you can use security scanning tools to check for vulnerable dependencies in your software bill of materials (SBOM). As a direct test, presenting a certificate with many hostnames to a patched application in a non-production environment should not result in excessive resource consumption.

Typical attack path

1. Attacker identifies a target service built with a vulnerable Go version that processes client-provided certificates.
2. Attacker generates a malicious X.509 certificate containing an abnormally large number of hostnames.
3. Attacker initiates a TLS connection to the target service.
4. During the TLS handshake, the attacker presents the malicious certificate to the server.
5. The Go application fails to validate the certificate and triggers the vulnerable `HostnameError.Error()` function.
6. The application's CPU and memory usage spike to 100% as it attempts to construct a large error string, leading to a denial of service.

How to detect it

To detect exploitation, monitor Go applications for sudden and sustained spikes in CPU and memory usage that are not associated with legitimate traffic patterns. Correlate these resource anomalies with logs from network devices or load balancers that show incoming TLS handshakes with abnormally large certificate payloads. Application performance monitoring (APM) tools may reveal that processes are stuck inside the `crypto/x509.HostnameError.Error` function. Application logs may contain extremely long, truncated error messages related to hostname validation, but the DoS condition itself may prevent logs from being written.

What your security team should do

• Immediately identify all applications built with Go that are exposed to external networks and process client certificates.
• Prioritize upgrading the Go toolchain on all build servers and developer machines to a patched version.
• Rebuild and redeploy all identified Go applications, starting with the most critical and publicly-exposed services.
• If patching cannot be done immediately, consider implementing a temporary mitigation at the network edge (e.g., WAF or reverse proxy) to reject TLS handshakes involving certificates with an unusually large size or an excessive number of SAN entries.