Kubernetes 1.34 Goes Dark on October 27, and the Last Security Patch Already Shipped

Kubernetes 1.34 reaches end of life on October 27, 2026. The Kubernetes release team has published the date, and it does not move. A cluster that stays on 1.34 past that point is running a branch upstream has stopped patching.

The last patch for 1.34 closed two flaws

CVE-2026-2270 is a confused deputy bug in the StatefulSet controller, rated 5.9. A user with namespace-scoped write permission on StatefulSet and ControllerRevision objects can make the controller restore more than the workload spec, including metadata, and place a pod in a namespace the user does not own. The fix restores only the spec field from a ControllerRevision. The fixed builds are kube-controller-manager 1.34.12, 1.35.9, 1.36.5 and 1.37.1.

The advisory is careful about a detail most summaries skip. The cross-namespace pod is deleted by the garbage collector immediately unless the attacker can build a valid StatefulSet owner reference, which requires the UID of a real StatefulSet in the target namespace. That lowers the odds of a blind attack from outside. It does not lower the odds from inside a cluster where one team can write both object types.

CVE-2026-19444 is a path traversal in kubectl cp on Windows, rated 6.5. A malicious tar binary inside a container can write files to arbitrary paths on the machine of a user who copies files out of that container, bounded only by the local user’s permissions. Linux and macOS clients are not affected. The fixed builds are kubectl 1.34.12, 1.35.9, 1.36.5 and 1.37.1.

End of life is a harder stop than maintenance mode

The Kubernetes project supports a minor version for about fourteen months. The first twelve months are standard support. The last two are maintenance mode, and during maintenance mode the release managers accept only CVE-labeled vulnerabilities, dependency issues and critical core component problems. That is the phase 1.34 has been in since August 27.

End of life ends even that. Cherry picks to the branch close shortly afterward, so any flaw found in 1.34 code later is the operator’s problem to solve without upstream help. That is not a distant concern. 1.33 reached end of life on June 28, 2026. The lines still receiving patches are 1.35, 1.36 and 1.37, and each monthly patch window is published in advance.

Upgrading is the easy part, then audit the permission

For a single-tenant cluster the work is a normal upgrade and the deadline is the only real issue. For a multitenant cluster the deeper problem is the permission that made CVE-2026-2270 exploitable at all. An identity that can write both StatefulSets and ControllerRevisions is a configuration most clusters never needed.

That permission is worth a look even after the version moves, because it is the same shape of over-grant that turns a medium bug into a real one. Tighten it once and the next ControllerRevision flaw arrives with the door already shut.

Three questions are worth answering before the branch closes. Who in this cluster can write to both StatefulSets and ControllerRevisions, and does any of them need to. What is the runbook if a CVE lands on a 1.34 node pool in November. And which supported minor takes our next upgrade, and when does that patch window open.

Related reading. The same pattern showed up in why the Dell Container Storage Modules fix still carried a flaw, and in what breaks when a cgroup v2 memory limit reads wrong.