GPU VulnDB

Database/Container, Kubernetes & orchestration

etcd: TCP connections that never send a ClientHello pile up goroutines until the process exhausts memory

CVSS 8.7CVE-2026-73500Container, Kubernetes & orchestrationcurated

Impact

Every connection accepted by tlsListener.acceptLoop in client/pkg/transport/listener_tls.go spawns a goroutine that blocks inside tls.Conn.Handshake() and stays in the pending map. An attacker who can reach the listener opens many TCP connections and never completes a handshake, so goroutines and map entries grow without bound until etcd runs out of memory. No certificate or credential is needed, because the abuse happens before the handshake that would check one. Where etcd backs Kubernetes, losing the etcd quorum takes the cluster control plane with it: no scheduling, no pod churn, no admission decisions, so GPU jobs that need to be placed or restarted stall even though running workloads keep their devices. Fixed in 3.5.33, 3.6.14 and 3.7.1.

Who can reach it

Anyone with TCP reachability to an etcd client or peer TLS listener. Unauthenticated - no client certificate or ClientHello required.

What to do

Upgrade etcd to 3.5.33, 3.6.14 or 3.7.1 and restart members one at a time so quorum is preserved; no node drain or reboot. Until patched, confirm the etcd listeners are reachable only from the control plane network and not from tenant or pod networks, and keep a connection-rate limit or firewall in front of them.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.