The vulnerability arises from the TLS listener’s acceptLoop spawning a new goroutine for each incoming TCP connection without imposing any deadline or limit. A malicious actor can open many connections and refrain from sending a TLS handshake, causing each goroutine to block forever inside tls.Conn.Handshake() and remain in a pending map. The unbounded growth of goroutines and the map can deplete the etcd process’ memory, leading to a loss of availability for the entire cluster and, when used in a Kubernetes control plane, a denial of service for the control plane itself. This is a classic denial‑of‑service weakness, classified as CWE-770.

The affected product is etcd from etcd-io. Vulnerable versions are all releases prior to 3.5.33, 3.6.14, and 3.7.1. Any installation of etcd in that range that exposes a TLS listener to the network is susceptible.

The vulnerability has a CVSS score of 8.7, indicating a high severity. The EPSS score is unavailable, and it is not listed in the CISA KEV catalog, which suggests no confirmed public exploits yet. The likely attack vector is network-based; any host that can reach an etcd TLS listener can initiate the attack by opening numerous TCP connections and not completing the TLS handshake. The exploit requires no authentication and can be performed from outside the cluster, making it a low‑threshold threat for attackers with network reach to the listener.