Kubernetes 1.34 Stops Receiving Patches on 27 October 2026

TL;DR

• Kubernetes is an open-source system that runs containerised workloads across a cluster of machines, and its releases follow a numbered minor version that receives patches for a fixed period.
• The releases page lists 27 October 2026 as the end-of-life date for version 1.34 and 1.34.12, released on 15 September 2026, as its latest patch.
• The fourteen months a minor release receives split into twelve months of standard patching and two months of maintenance mode, during which only CVE-tracked vulnerabilities, dependency and base-image issues, and critical core component problems can prompt a release.
• The project maintains three branches at a time: 1.35 closes on 28 February 2027, 1.36 on 28 June 2027 and 1.37 on 28 October 2027.
• The project has released patches after an end-of-life date before, for 1.26, 1.25 and 1.24 when a CVE or a Go update forced it, so the date marks the end of a commitment and the start of an exception process.
• A plan for a small platform team starts with a register of clusters taken from the API, continues with one target version tested against its manifests, and ends with a change window booked inside the monthly patch calendar.

What changes on 27 October 2026

Several things stop on that date, and they are easy to conflate. Cherry picks into the release-1.34 branch close soon after end of life, which means no further patch release for the branch. The project stops treating a defect in 1.34 as something it owes anyone a fix for. The gap between the last maintenance release and the next one widens into permanence.

The final two-month maintenance period was already a narrower regime. The project's patch release page describes it as a two-month window in which release managers may cut additional releases for a defined list: vulnerabilities with an assigned CVE ID, under the advisement of the Security Response Committee; dependency issues, base image updates included; and critical core component issues. A bug outside those categories waits for a version upgrade.

The fourteen months a minor release receives

The Kubernetes patch-releases page at https://kubernetes.io/releases/patch-releases/ sets the support period at roughly fourteen months under the project's yearly support KEP: twelve months treated as the standard period, then two months of maintenance mode, then end of life. The 28th of the month was chosen for both dates because every month has one, which is why the calendar reads as a pattern.

That clock starts at release, so the end date is visible from the day a version ships. An operator who tracks a cluster against its upstream version has fourteen months of notice and no dependency on an announcement. The end-of-life date is a published planning target. The project cautions that release timelines may vary with the severity of bug fixes.

Which branches still receive patches

Three branches are active as of 23 October 2026, and the releases page lists each with its latest patch and its end-of-life date. Version 1.37 sits at 1.37.1, released on 15 September 2026, and closes on 28 October 2027. Version 1.36 sits at 1.36.5 of the same date and closes on 28 June 2027. Version 1.35 sits at 1.35.9, also 15 September 2026, and closes on 28 February 2027.

Version 1.34 leaves that list on 27 October, with 1.34.12 as its latest patch, and the branch behind it, 1.33, closed on 28 June 2026 at 1.33.13. Version 1.32 closed on 28 February 2026 at 1.32.13. The releases page states the consequence plainly: end-of-life releases no longer receive security updates or bug fixes.

The exceptions the project has made to its own dates

The end-of-life date is a commitment with a documented exception history, recorded on the Kubernetes patch-releases page at https://kubernetes.io/releases/patch-releases/. Version 1.26.15 was released in March 2024, after the 1.26 end-of-life date, to pick up a new version of Go that addressed several Go CVEs. Version 1.25.16 followed in November 2023, after its end-of-life date, to fix CVE-2023-5528. Version 1.24.17 arrived in August 2023, after that branch closed, to fix CVE-2023-3676 and CVE-2023-3955.

Read those notes as the shape of the exception: a serious vulnerability in the language toolchain or the cluster itself can still pull a patch out of a closed branch. Nobody should schedule against that. An exception release arrives only when the project decides the risk justifies it.

The dependency trail that a closed branch leaves behind

Maintenance mode's second category is the one that spreads beyond the cluster: dependency issues, including base image updates. A branch that still receives maintenance releases can pick up a rebuilt base image with a patched system library underneath, and a branch that has closed stops receiving those rebuilds from the project.

That consequence reaches the scanning pipeline. An image that the project rebuilt in September still carries a September-era base, and a scanner that reads image metadata will keep reporting whatever the base contains for as long as the image stays in the registry. The fix moves into the operator's own rebuild process, with its own owner and its own schedule.

The upgrade path off a closed branch

A cluster on 1.34 has a fixed end date and a documented path forward. The project's monthly patch calendar stays the reference point: it targets monthly release points, warns that timelines may vary with bug-fix severity, and allows for unplanned critical releases between them. Booking the upgrade beside a planned monthly release keeps the target version and its patches in the same change window.

The intermediate versions carry their own deprecations, so the upgrade plan follows the release notes in sequence. A team moving from 1.34 to 1.37 reads three sets of notes, removes what a later version dropped, and tests the manifests against a staging cluster at the final version before touching production.

A plan for a small platform team

Start with a list of every cluster and its version, taken from the API. Compare each entry against 1.37.1, 1.36.5 and 1.35.9, and mark anything on 1.34 or older as unfinished.

Then pick one target version and test the manifests against it. The Kubernetes v1.37 volume changes are worth a specific test if the cluster mounts persistent volumes, because storage behaviour is where an upgrade turns into an incident.

Then schedule the change inside a patch window, upgrade one cluster at a time, and record the version each cluster actually reports afterwards. That register is the artefact that makes the next end-of-life date a calendar entry: 1.35 closes on 28 February 2027, and a team that records its versions today will see it coming.

For teams that run clusters on their own hardware, the sovereign infrastructure and cloud exit page lists related infrastructure topics. The dates are published years ahead. The work is a list, a test and a change window, repeated for each minor release.

Sources

Source: Releases — Kubernetes, kubernetes.io/releases/, retrieved 2026-10-23 (release branches maintained for the three most recent minor releases, 1.37, 1.36 and 1.35; approximately 1 year of patch support for 1.19 and newer and approximately 9 months for 1.18 and older; 1.37 latest release 1.37.1 of 2026-09-15 with end of life 2027-10-28; 1.36 latest release 1.36.5 of 2026-09-15 with end of life 2027-06-28; 1.35 latest release 1.35.9 of 2026-09-15 with end of life 2027-02-28; 1.34 latest release 1.34.12 of 2026-09-15 with end of life 2026-10-27; 1.33 latest patch 1.33.13 with end of life 2026-06-28; 1.32 latest patch 1.32.13 with end of life 2026-02-28; end-of-life releases no longer receive security updates or bug fixes).

Source: Patch Releases — Kubernetes, kubernetes.io/releases/patch-releases/, retrieved 2026-10-23 (roughly fourteen months of support for active patch release series; the first twelve months as the standard period; maintenance mode for the final two months, during which release managers may cut releases for vulnerabilities with an assigned CVE ID under the advisement of the Security Response Committee, dependency issues including base image updates, and critical core component issues; end of life at the end of that period with cherry picks closed soon afterwards; the 28th of the month chosen for maintenance mode and end-of-life targets; typical monthly cadence, faster in the first patch releases after a minor release, with critical fixes released outside the cadence and no releases aimed at major holiday periods; monthly-release rows for October 2026 through January 2027 whose target-date cells currently render blank; 1.37 maintenance mode 2027-08-28 and end of life 2027-10-28 with next patch 1.37.2; 1.36 maintenance mode 2027-04-28 and end of life 2027-06-28 with next patch 1.36.6; 1.35 maintenance mode 2026-12-28 and end of life 2027-02-28 with next patch 1.35.10; the rendered 1.34 maintenance-mode and end-of-life date fields are blank; the separate Releases page lists 1.34.12 of 2026-09-15 and end of life on 2026-10-27; historical post-end-of-life releases 1.26.15 in March 2024 for Go CVEs, 1.25.16 in November 2023 for CVE-2023-5528, and 1.24.17 in August 2023 for CVE-2023-3676 and CVE-2023-3955).

Source: the Kubernetes releases page and patch releases page, both retrieved 2026-10-23 — every version number, date and support rule above traces to one of those two pages. Images are captures of the two project pages plus two Netics editorial diagrams. Related Netics page: sovereign infrastructure and cloud exit.