kube-controller-manager CVE-2026-2270

Requires an authenticated principal with namespace-scoped WRITE permissions on BOTH StatefulSet and ControllerRevision objects (PR:H). The affected component is kube-controller-manager at versions <= v1.34.11, <= v1.35.8, <= v1.36.4, and exactly v1.37.0. A key limiting factor: any cross-namespace pod created is immediately deleted by the garbage collector UNLESS the attacker constructs a valid StatefulSet OwnerReference, which requires knowing/referencing the UID of an existing StatefulSet in the victim's namespace - this is the concrete condition that makes the attack materially harder (AC:H) and elevates it from a transient nuisance to a persistent cross-namespace foothold. Practical impact is meaningful only in multi-tenant clusters where namespaces are a genuine isolation boundary. No user interaction required.

This is a genuine but constrained privilege-escalation/tenancy-boundary issue, best treated as Medium priority rather than an urgent fire. The vendor (Kubernetes SRC) rated it 5.9 Medium with CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N, and the metric choices are well-justified: PR:H reflects that the attacker must already hold namespace-scoped write permissions on both StatefulSet and ControllerRevision objects, and AC:H reflects that a persistent (non-transient) cross-namespace pod requires knowing/referencing the UID of an existing StatefulSet in the victim namespace to build a valid OwnerReference - otherwise the garbage collector immediately deletes the injected pod. There is no EPSS score, no CISA KEV listing, and no public proof-of-concept in the provided data, so this is not evidence of active exploitation. The high C:H/I:H stems from full attacker control over the resulting pod's spec and metadata in another namespace (confused-deputy abuse of the controller-manager's authority). One point worth flagging: because the impact crosses the Kubernetes namespace authorization boundary, a scope-changed rating (S:C) is defensible even though the vendor chose S:U - this would raise the score, so treat 5.9 as a conservative floor. Overall: prioritize patching in multi-tenant clusters where namespace isolation is a real trust boundary; deprioritize in single-tenant clusters where the attacker's existing write permissions already imply broad access.

An attacker who holds namespace-scoped write access to StatefulSet and ControllerRevision objects in their own namespace crafts a ControllerRevision whose restored data specifies pod metadata and a spec pointing at a victim namespace, abusing the StatefulSet controller (a confused deputy running with cluster privileges) to create a pod in that other namespace. To make the pod persist rather than be garbage-collected, the attacker references the UID of an existing StatefulSet in the victim namespace to forge a valid OwnerReference. No public exploit code was identified at the time of analysis.