Which versions of etcd are affected by CVE-2026-73500?

etcd, the core database of Kubernetes control planes, is vulnerable to unauthenticated denial-of-service attacks (CVE-2026-73500) that crash clusters through memory exhaustion via incomplete TLS…. A patch is available.

How to fix or mitigate CVE-2026-73500?

Within 24 hours: identify all systems running etcd, document versions and network exposure, and list dependent Kubernetes clusters. Within 7 days: apply the vendor-released patch to etcd in non-production environments and verify stability. Within 30 days: deploy the patched etcd to all production Kubernetes clusters and confirm control-plane health.

etcd CVE-2026-73500

Q: What is the CVSS score of CVE-2026-73500?

CVE-2026-73500 has a CVSS 4.0 base score of 8.7 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.4%.

EUVD-2026-57642 HIGH

Allocation of Resources Without Limits or Throttling (CWE-770)

2026-08-12 GitHub_M

GHSA-6vch-q96h-7gc3

Denial Of Service Kubernetes Etcd

8.7

CVSS 4.0 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

8.7 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

7.5 HIGH

Network vector, no authentication or user interaction required; impact is solely availability (memory exhaustion crash); scope unchanged as the etcd process itself is the target system.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

SUSE

MEDIUM

qualitative

Red Hat

7.5 HIGH

qualitative

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Aug 12, 2026 - 22:16 vuln.today

Analysis Generated

Aug 12, 2026 - 22:16 vuln.today

Patch available

Aug 12, 2026 - 22:03 EUVD

CVE Published

Aug 12, 2026 - 21:22 cve.org

HIGH 8.7

DescriptionCVE.org

etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.5.33, 3.6.14, and 3.7.1, a network attacker who can reach an etcd TLS listener can open many TCP connections and never send a ClientHello. In client/pkg/transport/listener_tls.go, each connection handled by tlsListener.acceptLoop spawns a goroutine that blocks indefinitely inside tls.Conn.Handshake() and remains tracked in the pending map. Unbounded goroutine and map growth can exhaust memory in the etcd process, causing loss of availability for the cluster and, when etcd backs Kubernetes, the control plane. This issue is fixed in versions 3.5.33, 3.6.14, and 3.7.1.

Articles & Coverage 1

News 3 New Kubernetes Vulnerabilities - 1 Critical, 2 High Severity Aug 13, 2026

AnalysisAI

Memory exhaustion in etcd's TLS acceptor loop allows unauthenticated network attackers to crash etcd clusters - and the Kubernetes control planes they back - without completing a TLS handshake. The vulnerable code path in client/pkg/transport/listener_tls.go spawns a goroutine per inbound TCP connection with no timeout, meaning connections that never send a ClientHello block indefinitely inside tls.Conn.Handshake() and accumulate in an unbounded pending map. Exploitation is trivially automatable: no special protocol knowledge is needed beyond initiating TCP connections. No public exploit code or CISA KEV listing exists at time of analysis, but the Kubernetes control plane dependency elevates real-world blast radius well beyond a standalone etcd outage.

Technical ContextAI

etcd (CPE: cpe:2.3:a:etcd-io:etcd) is a Go-based distributed key-value store serving as the authoritative state backend for Kubernetes clusters. The flaw resides in client/pkg/transport/listener_tls.go within the tlsListener.acceptLoop function. In the vulnerable code path, each accepted TCP connection triggers an immediate goroutine spawn and a pending map entry before any deadline is applied to the underlying net.Conn. The goroutine then calls tls.Conn.Handshake(), which - absent a deadline - blocks forever if the peer sends nothing. CWE-770 (Allocation of Resources Without Limits or Throttling) precisely describes the root cause: the server allocates OS goroutines and heap-resident map entries for every inbound connection with no upper bound and no garbage collection path for stalled entries. PR #22130 introduces a tlsHandshakeTimeout constant of 10 seconds and applies it via tlsConn.SetDeadline() before the handshake call, with the deadline cleared afterward for legitimate connections. The fix is confirmed across commits 2e07efce, 89ff6d50, 8e4dd067, and f73cba7d.

RemediationAI

The primary fix is upgrading to etcd 3.5.33, 3.6.14, or 3.7.1 depending on the deployed branch; release artifacts are available at https://github.com/etcd-io/etcd/releases/tag/v3.5.33, https://github.com/etcd-io/etcd/releases/tag/v3.6.14, and https://github.com/etcd-io/etcd/releases/tag/v3.7.1. For environments where immediate upgrade is not feasible, the vendor-recommended workaround is to restrict network access to etcd's client (gRPC) port using firewall rules or Kubernetes NetworkPolicy, permitting only known API server IPs and authorized administrative hosts. This workaround reduces the attack surface but does not eliminate the vulnerability - any host that retains access could still exploit it, and misconfigured or overly broad firewall rules may leave exposure. Network-level restriction also introduces operational overhead for dynamic environments. There is no application-layer configuration knob to set a handshake timeout in affected versions; the fix is exclusively a code change, making patching the only complete remediation.