Build1 publisher2 min readPublished
Kubernetes stops StatefulSet rollbacks from carrying a tenant's pod into another namespace
Kubernetes fixed CVE-2026-2270 on September 23. The StatefulSet controller bug let a user confined to one namespace get a pod created in another. Shared clusters need the upgrade and a review of cluster-wide controllers that copy fields from objects tenants can write.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Exploiting the bug took write access to both StatefulSets and ControllerRevisions, but only in the attacker's own namespace.
- Patched versions restore only the spec field when rolling a StatefulSet back from a ControllerRevision; the old code restored additional fields.
- Kubernetes' garbage collector deleted such a cross-namespace pod almost immediately if it had no valid owner in its new namespace.
- Keeping the pod alive required an OwnerReference carrying the UID of a real StatefulSet in the victim namespace, which the post says cannot be guessed from outside.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure On an unpatched cluster, a tenant with ordinary workload permissions who learns one StatefulSet UID in a neighbour's namespace can keep a pod running there.
- cost The upgrade lands on whoever runs kube-controller-manager; tenants in a shared cluster have no way to close the hole from inside their own namespaces.
- decision Operators now have to decide whether tenants need write access to ControllerRevisions at all, since an ordinary-looking grant opened a cross-namespace path.
The StatefulSet controller runs inside kube-controller-manager and has no namespace scope [5]. It needs that reach because its job is to watch StatefulSets in every namespace and reconcile what exists against what is declared [5]. When a StatefulSet is updated, the controller saves the previous configuration as a ControllerRevision so it can roll back later [3]. Those snapshots are ordinary API objects. In some multi-tenant clusters, developers get write access to them along with the rest of their workload objects [4]. "It was confused because it trusted data it should not have trusted," the author of a dev.to write-up on the bug wrote of the controller [11].
Before the fix, a tenant could write a revision holding a StatefulSet whose metadata pointed at another namespace [7]. On restore, the controller created the pod where the snapshot said. The attacker chose that pod's metadata and specification [7]. The tenant did not bypass RBAC or raise their own permissions [10]. "The cluster did the crossing. The user just pointed," the author wrote [12].
The destination namespace was in the snapshot's metadata, outside spec. A spec-only restore therefore stops the controller from taking the namespace from tenant-written data [1]. I think this is the right fix. It limits what a cluster-wide process copies out of a tenant's object to the workload definition, and rollbacks still restore that definition [6].
The second condition in the post [15] made the garbage collector a security control, an odd job for a cleanup process [8]. I would not count it as a boundary. It deletes the pod only after the controller has already created it in the other namespace [8].
According to the post, the pattern behind the bug "shows up everywhere" [13]. For a shared cluster, the check that follows is concrete. Take each controller that runs without a namespace scope and list the objects it reads that tenants can write. Then list which of their fields it copies into objects it creates. In the StatefulSet case, one of those copied fields decided which namespace the pod landed in [1].
What to watch
- The Kubernetes advisory's list of patched releases, and whether older supported branches received the spec-only restore.
- Any report of another cluster-wide controller copying metadata out of tenant-writable objects, the recurring pattern the write-up describes.
- Any documented way for one tenant to learn StatefulSet UIDs in another namespace, the condition for a persistent pod on unpatched clusters.