If you run Windows nodes in Kubernetes and let non-admins create pods and PersistentVolumes, this week’s patch is non-negotiable: v1.25.16 fixes a critical privilege-escalation in the Windows in-tree storage path that can let a PV-creator become an administrator on the node.
The fix is concrete and narrow: clusters built with older v1.25.x releases where Windows in-tree storage plugins are present can be exploited by principals who already have the ability to create Pods and PersistentVolumes. The exploit path abuses the in-tree storage code on Windows to escalate to admin on the node—a local privilege escalation that’s particularly nasty because it pivots from an otherwise common developer capability (creating PVCs/PVs) to full node control. The release is published as v1.25.16.
Upgrade affected clusters. This is a critical patch for any environment with Windows workloads and non-restricted Pod/PV creation. Don’t treat v1.25 as ancient: it’s still in the support window for many users, and enterprises often run long-lived Windows nodepools due to application constraints.
What else moved this week
Upstream also published recent patch and alpha releases for other minors; check the official Kubernetes release notes for the exact version numbers and schedule. If you want alpha context, see our earlier note on v1.37.0-alpha.1.
Downstream and runtime ecosystem
GKE and other managed providers continue rolling out 1.36-based builds and security updates; expect providers to prioritize backports for the Windows fix for customers running Windows nodepools. In the same window we did not observe a separate, related runtime CVE cascade affecting containerd, runc, or other primary OCI tooling—this week’s highest-risk item is the Windows in-tree storage issue in Kubernetes itself.
Why this matters (and a blunt take)
Windows support in Kubernetes has always had fewer contributors, a larger in-tree surface area, and more long-lived cruft than Linux. Keeping Windows in-tree storage in the core repo after CSI drivers were available left an obvious attack surface. This CVE is the predictable payoff you get when platform-level drivers remain inside the monolith: core must carry fixes, backports, and coordination across many release trains.
Keeping in-tree Windows storage in core past the point where CSI equivalents exist is a mistake the ecosystem should have moved on from sooner. The practical result is repeated critical fixes that force emergency backports and downstream churn.
Final thought
If you run Windows workloads: schedule v1.25.16 into your next maintenance window and prioritize Windows nodepools for the upgrade. If you run newer minors, track the current stable patch line and upcoming alphas—alpha cuts are for integration testing, not production stability. Longer term: if you care about reducing blast radius and maintenance complexity, migrate Windows storage to CSI-based solutions and shrink the core Windows surface area before the next predictable emergency hits.