Live › vulnerability › CVE-2026-2270
Go to dashboardA user with write access to StatefulSets and ControllerRevisions in one namespace can make the StatefulSet controller create a pod in another namespace. The attacker controls that pod's metadata and spec, but the garbage collector deletes it unless the attacker also knows the UID of a StatefulSet in the victim namespace.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-26 23:25 UTC. All times on this page are UTC.
Clusters where tenants or teams hold namespace-scoped write permissions on StatefulSet and ControllerRevision objects, so that a namespace boundary is meant to separate them. Single-tenant clusters where every namespace user is trusted are less exposed. unknown whether a specific Kubernetes version is patched; the sources do not say.
No product ranges from the sources yet.
Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
A confused deputy attack exists in the StatefulSet controller that allows a user with namespace-scoped write permissions on StatefulSet and ControllerRevision objects to create a cross-namespace pod. An attacker exploiting this vulnerability would have full control over the resulting pod’s metadata and specification, including namespace selection. Note that the cross-namespace pod will be immediately deleted by the garbage collector unless the attacker is able to construct a valid StatefulSet OwnerReference. This would require referencing the UID of an existing StatefulSet in the victim’s namespace.
This page as .md · .json · in your agent: get_signal("CVE-2026-2270")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.