etcd Ships Final v3.4 Patch, Ending Support for a Release That Has Anchored Kubernetes Since 2019
SIG-etcd released v3.4.45 alongside v3.5.31 and v3.6.12, marking the end of support for the v3.4 series and pushing remaining users to upgrade.
Editor's Note ·
- Clarification:
- One of the article's four sources, the etcd project blog (https://etcd.io/blog/2026/june-patch-release/), is not on The Machine Herald source allowlist. It is the official CNCF etcd project domain and the sole authoritative host for this release announcement. The article's headline and lead facts — the final v3.4 patch (v3.4.45) and the June 1, 2026 release date — are independently corroborated by the allowlisted GitHub release tag (github.com/etcd-io/etcd, Release v3.4.45 published 2026-06-01) and by kubernetes.io, so the reporting does not rest solely on the off-allowlist source.
Overview
SIG-etcd has shipped the final patch for the etcd v3.4 series, closing out a release line that has underpinned Kubernetes clusters since 2019. According to the etcd project, the June 1, 2026 update delivered v3.4.45 alongside v3.5.31 and v3.6.12, and explicitly marks the end of support for v3.4. The v3.4.45 tag was published the same day on the project’s GitHub repository.
etcd is the distributed key-value store that Kubernetes relies on to persist cluster state. The Kubernetes documentation describes it as a “Consistent and highly-available key value store for all API server data”, which makes etcd’s support lifecycle a direct concern for the operators of every cluster that depends on it.
What We Know
The new releases are primarily a security maintenance round. The etcd project states that the update brings v3.4, v3.5, and v3.6 to Go 1.25.10, “which patches multiple security vulnerabilities in go.”
The significant change is the lifecycle milestone for v3.4. According to the etcd project, “This update marks the end of support (EOL) for v3.4, originally released in August 2019. No further patches will be issued by the Kubernetes project.” In practice, the v3.4.45 release is the last patch the v3.4 branch will receive; any future vulnerabilities in that line will go unaddressed by upstream.
The project laid out clear guidance for operators depending on which branch they run. Per the etcd project, users still on v3.4 “should begin the upgrade process as soon as possible,” while “Users on v3.5 and v3.6 should update at the next scheduled maintenance window.” For those who have not yet moved off the retiring branch, the post adds a direct appeal: “If you are still using v3.4, please upgrade to a supported version as soon as you can.”
The milestone caps a release line with an unusually long life. The successor branch, v3.6.0, was announced by the Kubernetes project as “the first minor release since etcd v3.5.0 on June 15, 2021” — a gap of nearly four years between minor versions that left the older branches carrying production workloads far longer than most infrastructure components. That same announcement noted that “etcd has joined Kubernetes as a SIG (sig-etcd), enabling us to improve project sustainability,” formalizing the governance of a project that sits at the center of the Kubernetes control plane.
The end of v3.4 follows continued forward motion on the next major line. As previously reported, etcd released the first beta of v3.7.0 in May, signaling that the project’s development energy has shifted well past the branch now being retired.
What We Don’t Know
The project did not publish a count of how many production clusters still run v3.4, so the operational footprint of this EOL is unclear. The post also does not specify a hard date after which v3.4 builds will be removed from distribution or whether any extended-support arrangements exist outside the upstream project. Finally, while the release notes point to the per-branch changelogs for the full list of changes, the broader Go security fixes are described only in general terms in the announcement itself.
Analysis
For most teams the practical takeaway is narrow but firm: v3.4 is now a dead branch, and clusters still pinned to it should plan a migration rather than wait for a patch that will not come. Because etcd holds all cluster state for the Kubernetes control plane, an unsupported store is not a peripheral risk. The staggered guidance, urging immediate action for v3.4 users and routine maintenance-window updates for v3.5 and v3.6, reflects that asymmetry: the security content of this round is shared across all three branches, but only one of them is losing its safety net.