etcd Vulnerabilities by Version: CVEs for etcd 3.3, 3.4, 3.5, 3.6 and 3.7

The short answer

SIG-etcd patches three lines today: 3.5, 3.6 and 3.7, whose latest releases, 3.5.34, 3.6.15 and 3.7.2, all shipped on 22 September 2026. etcd 3.4 reached end of life on 1 June 2026 with 3.4.45. Six etcd CVEs have been published in 2026, and the three supported lines have fixes for all of them. 3.4.45 has fixes for three. The other three, CVE-2026-59818, CVE-2026-73499 and CVE-2026-73500, were published after 3.4 ended, and their ranges cover every release below the first fixed 3.5 patch, so 3.4 and everything older are inside them with no upstream fix coming.

Whether a CVE reaches a given cluster depends heavily on how it is run. Four of the six are authorization bypasses that only matter when etcd's own authentication is enabled. The advisories say typical Kubernetes deployments are not affected by three of them, because the API server does its own authorization and does not use etcd's. CVE-2026-73500, a memory exhaustion through the TLS listener, has no such condition.

etcd release lines and their CVEs

Release dates are from the etcd GitHub releases and the 3.4 end-of-life date from the SIG-etcd post of 1 June 2026. Each row lists the etcd CVEs whose ranges include the line and that have no fix in its latest release.

The branch policy in the etcd contributor guide says the project fixes bugs on the latest two stable releases, yet three are patched now. No date has been published for the end of 3.5, so it is the line to watch next. For dates on every line, see the etcd end-of-life chart.

Notable etcd CVEs by release line

CVSS is NVD's own score where NVD has scored the record. NVD has not yet analysed CVE-2026-73499 or CVE-2026-73500 and CISA-ADP has added no score, so for those two the score is the CVSS 4.0 score in the CNA record, which GitHub published from the etcd advisory. None of these CVEs is in CISA's Known Exploited Vulnerabilities catalogue.

The 2026 list splits three ways. CVE-2026-33413, CVE-2026-33343, CVE-2026-44283 and CVE-2026-73499 are RBAC bypasses, so they matter only where etcd authentication is turned on and more than one identity uses the cluster, as with an etcd shared by Patroni, APISIX or other applications. CVE-2026-59818 matters only where the HTTP and gRPC client listeners are split and a revocation list is relied on to cut off a client. CVE-2026-73500 needs nothing but network access to a TLS port, which is why it is the one to worry about on a 3.4 control plane. The 2020 rows came from the security audit report the etcd project published that year; most concern the gateway and the WAL and matter now only to clusters still on 3.3.22 or 3.4.9 and earlier.

The Go toolchain matters as much as the etcd code. The June 2026 releases moved 3.4, 3.5 and 3.6 to Go 1.25.10 to pick up a batch of Go CVEs, and SIG-etcd said it does not know how many of them are reachable in etcd. 3.4.45 is the last 3.4 build, so it will not get later toolchain updates.

What each line gets

etcd 3.7

3.7.0 shipped on 8 July 2026, and 3.7.1 followed on 23 July with the fixes for CVE-2026-73499 and CVE-2026-73500. 3.7.2 is current.

etcd 3.5 and 3.6

Both lines carry every fix above. Patch releases have come roughly monthly through 2026, and the June releases also moved to a newer Go toolchain, so staying on the latest patch is the main task. 3.5 has no announced end date, but it is the oldest of the three supported lines.

etcd 3.4

3.4.45 has the fixes for CVE-2026-33343, CVE-2026-33413 and CVE-2026-44283. It does not have the fixes for CVE-2026-59818, CVE-2026-73499 or CVE-2026-73500, all fixed upstream only in 3.5 and later. Moving to 3.5 is the next step, and the upgrade guide has extra conditions for clusters with authentication enabled; see upgrading etcd 3.4 to 3.5 and 3.6 and etcd 3.4 end of life.

etcd 3.3 and older

3.3.27, from October 2021, has the 2020 audit fixes from 3.3.23 and nothing since. It is inside the ranges of every 2026 CVE and of CVE-2023-32082. The 2020 fixes were published only for 3.3 and 3.4, so 3.2 and older lines do not have them either.

What to do on each line

• 3.5, 3.6 and 3.7. Take 3.5.34, 3.6.15 or 3.7.2, and keep taking patch releases as they ship.
• 3.4. Plan the rolling upgrade to 3.5, or take patched builds from a supplier that backports fixes. Until then, limit which hosts can reach the client and peer ports, require client certificates, and if you rely on --client-crl-file with split listeners, do not count on revocation for gRPC clients.
• 3.3 and older. Move to 3.4 and then 3.5 through tested snapshots, or take patched builds. Where auth is enabled, review every READ grant and treat any authenticated identity as able to read the whole keyspace until the upgrade.

etcd often replaces ZooKeeper as the coordination store for other systems, so an upgrade touches them too; see moving Patroni from ZooKeeper to etcd and ZooKeeper, etcd, Consul and KRaft compared.

Where OSSeva fits

OSSeva ships patched, signed builds of etcd 3.4 and older, with the same data format, rebuilt on a supported Go toolchain with patched gRPC and dependencies, and covering the etcd, etcdctl and etcdutl binaries, delivered as binaries, Docker images and packages. OSSeva backports fixes of this class to the end-of-life release lines it patches. They are available now on the Patch, Assure and Operate tiers. Assure adds a member, quorum and failure-domain review, a TLS, authentication and client exposure audit, a snapshot backup design with a timed restore drill and an upgrade plan to 3.5 or later, and Operate adds 24/7 leader change, fsync latency and database size monitoring with a 15-minute P1 response, a named senior distributed systems engineer and rolling upgrades with quorum preserved. See etcd support and etcd extended support.