CVE-2026-32280

What it actually does

This vulnerability allows an unauthenticated remote peer to consume excessive CPU during X.509 certificate chain construction in Go applications. When a large number of intermediate certificates are supplied through VerifyOptions.Intermediates, the crypto/x509 verifier may perform unbounded or poorly bounded chain-building work. Because crypto/tls relies on crypto/x509 for certificate verification, Go-based TLS clients can be affected when connecting to a malicious server, and Go-based TLS servers can be affected when verifying malicious client certificates, especially in mutual TLS configurations. The result is denial of service through CPU exhaustion or thread/goroutine saturation during TLS handshakes or explicit certificate verification.

Why it matters to the business

Affected Go applications may become slow, unresponsive, or unavailable when exposed to crafted certificate chains. Internet-facing APIs, service meshes, mTLS-protected internal services, proxies, agents, and clients that connect to untrusted TLS endpoints are the highest-risk use cases. The CVSS availability impact is high, but current public exploitation indicators are low: EPSS is 0.00615, the 30-day trend is flat, there is no known KEV listing, and no ransomware association is reported. Even so, the issue is broadly relevant because Go is commonly used in infrastructure and cloud-native services.

How an attack unfolds

An attacker identifies a Go application that performs TLS certificate verification or directly verifies certificates using crypto/x509. If targeting a Go TLS server, the attacker initiates TLS handshakes and presents a client certificate chain containing an unusually large number of intermediate certificates, typically in environments where client certificate authentication is requested or required. If targeting a Go TLS client, the attacker operates or intercepts a TLS endpoint and presents a crafted server certificate chain with many intermediates. The vulnerable verifier attempts to build valid chains from the supplied intermediates and performs excessive computational work. By repeating these handshakes or verification attempts, the attacker drives high CPU usage, increases handshake latency, exhausts worker capacity, and can make the service unavailable without needing authentication or user interaction.

How to fix it

Rebuild and redeploy affected applications with a Go release that contains the upstream fix for this vulnerability as soon as an applicable patched version is available from the Go project or the application vendor. Because no fixed versions were provided in the input, validate remediation against the official Go security advisory and vendor release notes for the exact patched Go versions. For third-party products written in Go, upgrade to vendor releases that explicitly state they were rebuilt with a fixed Go toolchain. As interim mitigations, limit exposure of mTLS endpoints to trusted networks, enforce rate limits on TLS handshakes, cap maximum accepted client certificate chain size where supported by front-end proxies or load balancers, terminate TLS at infrastructure that is not vulnerable, and avoid passing untrusted or excessively large intermediate certificate pools into crypto/x509 verification code.

How to confirm the fix worked

Confirm the runtime and build toolchain versions for Go applications and verify they are at or above the patched Go versions identified by the official advisory. For packaged products, confirm the vendor release notes include this fix or a fixed Go runtime/toolchain. Use software composition analysis, SBOMs, container image metadata, and build provenance to identify binaries built with vulnerable Go versions. Functionally validate by testing TLS handshakes and certificate verification paths with normal certificate chains to ensure no regressions, and where safe in a controlled test environment, verify that oversized intermediate chains are rejected, rate-limited, or no longer cause excessive CPU usage. Also confirm that compensating controls such as handshake rate limiting, mTLS exposure restrictions, and TLS termination controls are active.

Typical attack path

1. Identify a Go-based service or client workflow that validates peer certificates using crypto/tls or crypto/x509.
2. Prepare a TLS certificate chain or verification input containing an abnormally large number of intermediate certificates.
3. For server-side impact, repeatedly initiate TLS handshakes and present the crafted client certificate chain where client certificate verification is enabled.
4. For client-side impact, lure or cause a Go-based client to connect to an attacker-controlled TLS endpoint presenting the crafted server certificate chain.
5. Trigger expensive X.509 chain-building operations during certificate verification.
6. Repeat connections or verification attempts to sustain CPU exhaustion, handshake backlog growth, latency, or service denial.

How to detect it

To determine whether exploitation may have occurred, review telemetry around Go applications that perform TLS handshakes or certificate verification. Focus on periods with sudden CPU saturation, increased TLS handshake latency, connection timeouts, elevated goroutine counts, or degraded availability without a matching increase in legitimate request volume. Inspect reverse proxy, load balancer, firewall, and application logs for repeated TLS handshakes from the same sources, excessive failed handshakes, or failures involving client certificate validation. Where packet capture or TLS metadata is available, look for Certificate handshake messages containing an unusually high number of certificates or unusually large certificate-chain payloads. For host forensics, examine process metrics, pprof profiles, crash dumps, and traces for hot paths in crypto/x509 certificate verification and chain building. Since exploitation does not necessarily write files or spawn distinct malware processes, detection is primarily behavioral and performance-based rather than artifact-based.

• crypto/x509.(*Certificate).Verify
• crypto/x509.buildChains
• crypto/x509.Certificate.Verify
• tls: failed to verify certificate
• remote error: tls: bad certificate
• x509: certificate signed by unknown authority
• TLS handshake error
• too many certificates
• certificate chain too large
• excessive TLS handshake failures
• abnormally large TLS Certificate handshake message
• high CPU in Go process during TLS handshakes

What your security team should do

• Inventory Go-based services, agents, CLIs, sidecars, proxies, and products that perform TLS or X.509 certificate verification.
• Prioritize internet-facing Go TLS services and mTLS-enabled services that accept client certificates from many or untrusted peers.
• Track the official Go security advisory and vendor advisories for exact fixed versions, then rebuild and redeploy affected binaries with the patched toolchain.
• Apply temporary handshake rate limits, connection throttling, and network access controls on exposed TLS endpoints until patched.
• Review TLS termination architecture and consider terminating untrusted TLS traffic at patched or unaffected infrastructure.
• Monitor for abnormal TLS handshake volume, elevated CPU in Go processes, and repeated certificate verification failures involving unusually large certificate chains.
• Add regression tests for certificate verification code paths that ensure large intermediate pools cannot cause excessive verification time.
• For Go clients that connect to untrusted URLs or endpoints, restrict destination allowlists where feasible and monitor outbound connections to newly observed TLS endpoints.