GHSA-6VCH-Q96H-7GC3: Unbounded Goroutine Creation and Denial of Service in etcd TLS Listener

The etcd distributed key-value store relies on a custom TLS listener implementation (tlsListener) to handle secure communication between cluster peers and client applications. This component wraps standard network connections and processes incoming TLS transport layers. The attack surface is exposed directly on the peer port (typically TCP 2380) and client port (typically TCP 2379) when TLS encryption is enabled.

An unauthenticated remote attacker can exploit a vulnerability within the connection acceptance loop (acceptLoop) of this listener. By initiating a large number of TCP connections and intentionally withholding the expected TLS handshake data, the attacker can force the server to allocate resources that are never released.

This bug belongs to the class of uncontrolled resource consumption (CWE-400). It permits an attacker with network reachability to exhaust available system resources on the etcd host, leading to node crashes and cluster-wide denial of service.

The core vulnerability resides in client/pkg/transport/listener_tls.go within the acceptLoop() method. When a new TCP connection is accepted via l.Listener.Accept(), etcd registers the connection in a synchronized pending map to track active handshakes. To prevent slow TLS handshakes from blocking the main acceptance loop, etcd spawns a new Go goroutine for each incoming connection to complete the TLS handshake process.

Inside the spawned goroutine, etcd calls tlsConn.Handshake(), which is Go's standard library implementation of the TLS handshake. However, Go's standard network sockets do not enforce any default read or write deadlines. If a client establishes a TCP connection but transmits no data, any blocking read operation on that connection will block indefinitely.

Because etcd failed to establish a handshake timeout or a read/write deadline on the underlying connection before calling tlsConn.Handshake(), the blocking read call within the standard library remains suspended indefinitely. This allows an attacker to leak goroutines, file descriptors, and memory indefinitely by simply opening raw TCP connections and remaining silent.

The vulnerable code path initiates the handshake directly without setting any deadline on the connection wrapper. The following diff illustrates the vulnerability and the subsequent remediation implemented in the patch:

// Prior to the patch:
tlsConn := conn.(*tls.Conn)
// Vulnerable: Handshake is called directly without a preceding SetDeadline call.
// The goroutine will block indefinitely if the client does not send a ClientHello.
herr := tlsConn.Handshake()
pendingMu.Lock()
delete(pending, conn)
pendingMu.Unlock()

The remediation introduces a constant handshake timeout of 10 seconds and applies it to the connection prior to executing the handshake:

// Patched implementation:
const (
	// tlsHandshakeTimeout bounds how long a single TLS handshake may block.
	tlsHandshakeTimeout = 10 * time.Second
)
 
// ...
 
tlsConn := conn.(*tls.Conn)
// Fix: Apply a 10-second deadline before calling Handshake
_ = tlsConn.SetDeadline(time.Now().Add(tlsHandshakeTimeout))
herr := tlsConn.Handshake()
pendingMu.Lock()
delete(pending, conn)
pendingMu.Unlock()
 
if herr != nil {
	l.handshakeFailure(tlsConn, herr)
	return
}
// Fix: Clear the deadline after a successful handshake to allow persistent streams
_ = tlsConn.SetDeadline(time.Time{})

This ensures that any connection failing to complete the TLS handshake within 10 seconds will trigger an I/O timeout, causing Handshake() to return an error, terminating the goroutine, and cleaning up the resources.

An attacker can exploit this vulnerability using a connection-gobbling pattern, similar to a classic Slowloris attack. The attack requires no cryptographic capability, credentials, or client certificates, making it effective even when mutual TLS (mTLS) is enforced. The handshake failure occurs before client certificate verification is executed.

The exploitation sequence begins with the attacker initiating a standard TCP three-way handshake with the target etcd port. Once the connection is established, the attacker halts all communication and does not send the standard TLS ClientHello message.

By repeating this cycle thousands of times, the attacker forces the etcd server to spawn a goroutine and allocate file descriptors for each connection. Because these goroutines remain active indefinitely, the host eventually exhausts its file descriptor limits or runs out of available RAM, causing the operating system to terminate the etcd process or refuse new connections.

The primary impact of this vulnerability is a complete denial of service. Since etcd serves as the state store for Kubernetes clusters and other distributed systems, a crash of the etcd daemon can destabilize the entire control plane.

The vulnerability has been assigned an estimated CVSS v3.1 score of 7.5 (High), with the vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The exploitation complexity is low, as it requires no privileges and can be executed over the network.

While there are no reports of weaponized exploits in the wild, the low technical barrier to entry makes this a significant risk. Organizations running etcd clusters exposed to untrusted networks are particularly vulnerable to resource exhaustion attacks.

The primary remediation strategy is upgrading the etcd cluster to a patched release. The fix is integrated into versions 3.5.33, 3.6.14, and 3.7.1.

If immediate upgrading is not feasible, several network-level mitigations can reduce the attack surface. Organizations should implement strict Access Control Lists (ACLs) at the firewall or security group level to limit access to etcd ports (2379 and 2380) solely to authorized client IPs and peer nodes.

Additionally, operators can deploy etcd behind a highly optimized TLS-terminating reverse proxy or load balancer. The proxy should enforce strict TCP handshake timeouts and limit the rate of concurrent connections from single source IPs, protecting the backend etcd listeners from resource exhaustion.