By Kubernetes 1.34 hits end of life on October 27 — twenty days from now. Two vulnerabilities landed in the patch queue on September 23 that won’t get another backport after that date. If your clusters are still on 1.34 in November, you’re running software the Kubernetes security community has quietly stopped caring about.
Two CVEs, Both Patched in 1.34.12
The September 23 patch release dropped fixes for two separate vulnerabilities. Neither is catastrophic in isolation, but both matter — and neither will ever be backported to 1.34 after October 27.
CVE-2026-19444 (CVSS 6.5) is a path traversal in kubectl cp that affects Windows clients only. When you copy files from a container, kubectl runs tar inside the container to bundle them, then unpacks the archive on your local machine. The Windows version failed to translate forward slashes to backslashes, which means an attacker who controls a container’s contents can craft a tar archive that writes files to arbitrary paths on the Windows admin machine — limited only by local user permissions. Linux and macOS are not affected. The fix is in kubectl v1.34.12, v1.35.9, v1.36.5, and v1.37.1.
CVE-2026-2270 (CVSS 5.9) is a confused deputy attack in kube-controller-manager. Before the fix, the StatefulSet controller restored more than just the workload spec from a ControllerRevision — it also restored metadata, including namespace fields. An attacker with write access to both StatefulSets and ControllerRevisions in their namespace could modify a ControllerRevision with a target namespace in the metadata, then wait for the controller to recreate the pod in that unauthorized namespace. This breaks namespace isolation, which is the foundational trust boundary in multitenant clusters. The official security advisory has full remediation details. Fixed in the same four versions above.
Neither CVE has confirmed exploitation in the wild. But “no known exploits yet” stops being reassuring once the vendor stops patching.
What October 27 Actually Means
Kubernetes 1.34 entered maintenance mode on August 27, which meant only critical security patches were being accepted. October 27 is the harder stop: the community stops reading 1.34 issues entirely. No CVE backports. No bug fixes. Any vulnerability discovered in 1.34 code paths after that date is your problem to solve without upstream help.
Three versions behind is already a long way to be behind. Kubernetes 1.37.1 is current stable.
The Cloud Provider Math
If you’re running on a managed service, the economics make the case for upgrading more bluntly than any CVE score does.
GKE standard support for 1.34 already ended on October 1 — that window is closed. EKS and AKS standard support ends December 2 and November 30, respectively, but extended support kicks in at $0.60 per cluster-hour, roughly $438 per cluster per month. At ten clusters, that’s $4,380 monthly. EKS adds a particularly unwelcome detail: once your standard support window closes on December 2, it will automatically upgrade your control plane to current stable without notice if you haven’t done it yourself.
That’s the kind of surprise upgrade that disrupts workloads at the worst time.
How to Upgrade
Check your current version first:
kubectl versionKubernetes only supports upgrading one minor version at a time, so the path from 1.34 is: 1.34 → 1.35 → 1.36 → 1.37. If you want to stop the bleeding now and test the upgrade process before the EOL date, upgrading to 1.34.12 immediately patches both CVEs and buys you time. The real target should be 1.36.5 or 1.37.1 to land in a supported window with meaningful runway.
For the CVE-2026-19444 fix specifically: the kubectl client version matters independently from the server version. Windows administrators should verify their client version with kubectl version --client and upgrade even if the cluster itself isn’t ready for a full minor version bump yet.
Audit Before You Upgrade
For CVE-2026-2270, the exploitability depends on which users or service accounts have write access to both StatefulSets and ControllerRevisions simultaneously. Before upgrading, run a permissions audit on your multitenant clusters. After upgrading, tighten those dual-write permissions anyway — it’s a configuration that shouldn’t exist for untrusted principals regardless of whether the CVE is patched.
Twenty days is enough time to plan and execute a version bump. It is not enough time to debate whether the risk is real. The Kubernetes community has already made their position clear: they’ve moved on.
