CVE-2026-2270: When StatefulSet History Crosses a Namespace Boundary

1. The finding: a controller becomes a confused deputy

A namespace can constrain a user's API requests without constraining every action a privileged controller later performs on that user's behalf. CVE-2026-2270 exposes that distinction in the StatefulSet controller. The Kubernetes advisory, published September 14, 2026, describes cross-namespace pod creation by a principal with namespace-scoped write permissions on both StatefulSets and ControllerRevisions. The attacker controls the resulting pod's metadata and specification. The published severity is Medium, CVSS 3.1: 5.9, with vector CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N. Official Kubernetes advisory.

The affected component is kube-controller-manager. Treat these as upstream patch boundaries, not a blanket assertion that older, unlisted or distribution-specific builds are safe. Confirm vendor backports and the deployed control-plane build. Affected and fixed versions.

2. Patch anatomy: restoring configuration must not restore authority

StatefulSets retain configuration history using ControllerRevision objects. These are controller inputs, not inert documentation: revision data is consumed when reconstructing a workload configuration. Kubernetes documents their role in rollback and version tracking. StatefulSet revision history.

In Kubernetes 1.36.4, ApplyRevision deep-copies the StatefulSet, applies a strategic merge patch using revision.Data.Raw, unmarshals the result into another StatefulSet and returns that restored object. The problem is the breadth of the returned object: revision-controlled material can influence more than the intended workload specification. In the same source file, updateIdentity derives the new pod's namespace from the StatefulSet representation it receives. Metadata therefore participates in deciding where controller authority is exercised. Vulnerable restoration and pod-identity code.

pseudocode · explanatory, not an exploitBefore:
  reconstructed = apply_revision_to_entire_statefulset(original, revision)
  return reconstructed

After:
  reconstructed = apply_revision_to_entire_statefulset(original, revision)
  original_copy.spec = reconstructed.spec
  return original_copy

The 1.36.5 implementation keeps the original object's identity-bearing metadata and copies back only the restored specification. The important distinction is the StatefulSet's top-level metadata versus metadata inside its pod template. Restoring a legitimate pod-template change remains possible; replacing the parent object's identity through revision history does not. This is an allowlist at the data-to-authority boundary, not merely a special-case check for one suspicious namespace value. Fixed ApplyRevision implementation.

The corresponding tests verify that specification changes apply while changes to top-level metadata, status and type metadata are ignored. They also cover clean, empty and malformed revision inputs. These tests support the patch's intended invariant; they do not demonstrate that any particular production cluster is running it. Upstream restoration regression tests.

A controller must not promote mutable historical data into authority over the identity or location of the object it reconciles.

3. Reconstruct the path—and stop where evidence stops

1. 1. Initial authorityA principal can write the relevant workload and revision objects in a source namespace.
2. 2. Restoration boundaryA vulnerable controller consumes revision data when reconstructing a StatefulSet.
3. 3. Controller actionReconstructed metadata influences the namespace and identity used for pod creation.
4. 4. Target-side resultAdmission, scheduling, ownership and runtime conditions determine the observable outcome.

This is a confused-deputy pattern: the initiating user's authority and the controller's downstream authority are different. The controller's pod-creation path is visible in the implementation. A denied direct pod-create request by the initial user is therefore not enough to rule out an indirect controller-mediated path. StatefulSet pod-creation implementation.

The garbage-collection caveat is material

The advisory says the cross-namespace pod is immediately deleted unless its owner reference identifies an existing StatefulSet UID in the destination namespace. Advisory ownership prerequisite. Kubernetes normally disallows cross-namespace ownership: a namespaced owner must exist in the dependent object's namespace. A missing owner can make the dependent eligible for deletion. Garbage-collection semantics.

Security interpretation: garbage collection is cleanup, not a substitute for preventing unauthorized creation. Equally, observing a create event does not prove the pod started, persisted, mounted data or reached another service. Establish those effects independently. Do not describe the vulnerability as an automatic container escape.

Conditional consequences, not guaranteed outcomes

Kubernetes warns that workload-creation rights can expose namespace resources and allow use of ServiceAccounts in that namespace. Applied here, a destination pod may become a route to sensitive workloads or identities, depending on its accepted specification and the controls in force. This is a risk assessment, not proof that CVE-2026-2270 always yields cluster-admin. RBAC guidance on workload creation.

4. Interactive investigation map

Expand a branch to connect the prerequisite, trust boundary and evidence. These branches are an investigation model—not a claim that all transitions occurred.

5. Am I exposed? Start with inventory, then effective permissions

Identify the deployed controller—not your local kubectl version

On a self-managed cluster where controller-manager pods are visible, this query records configured image references and observed image IDs without executing commands in workloads. Labels and visibility vary by distribution; managed services may require provider control-plane evidence instead.

bash · inventory onlykubectl -n kube-system get pods \
  -l component=kube-controller-manager -o json |
jq '.items[] | {
  pod: .metadata.name,
  images: [.spec.containers[] | {name, image}],
  runtimeImages: [
    .status.containerStatuses[]? | {name, imageID}
  ]
}'

Use the version table with the provider's patch/backport statement. Record the evidence for every controller-manager instance: an unpatched standby can matter after leadership changes. An image tag alone is weaker evidence than a verified digest and vendor build record.

Review the actual caller's permissions

Run the following with the principal's authorized credentials. It queries authorization decisions; it does not create or modify workloads. Using an administrator's credentials measures the administrator's rights, not the tenant's. Impersonation-based reviews additionally require correct user/group context and permission to impersonate. kubectl auth can-i reference.

bash · permission reviewnamespace="tenant-a"

for resource in statefulsets.apps controllerrevisions.apps; do
  for verb in create update patch; do
    printf '%s %s: ' "$verb" "$resource"
    kubectl auth can-i "$verb" "$resource" -n "$namespace"
  done
done

kubectl auth can-i create pods -n sensitive-namespace

This is triage, not an exploitability oracle. Review named-resource restrictions and the operations actually needed by the environment. Kubernetes RBAC grants are additive: adding a narrow Role does not cancel a broader grant from another binding. RBAC authorization model.

Look for unexpected top-level revision fields

This review query limits results to revisions with a StatefulSet owner and reports field names, not revision contents. A match is a lead for investigation, not a vulnerability verdict.

bash · structural triagekubectl get controllerrevisions.apps -A -o json |
jq '
  .items[]
  | select(any(.metadata.ownerReferences[]?; .kind == "StatefulSet"))
  | select(.data | type == "object")
  | select(.data | has("metadata") or has("status")
                   or has("kind") or has("apiVersion"))
  | {
      namespace: .metadata.namespace,
      revision: .metadata.name,
      uid: .metadata.uid,
      topLevelFields: (.data | keys)
    }
'

6. Detection engineering: correlate the initiator with the deputy

Build the investigation around a sequence, rather than a single object label. The following is a proposed detection model that must be tuned to your controller identities and normal automation.

Kubernetes audit levels determine what remains available. Metadata-level events support actor, resource and timing correlation but omit request and response bodies. Request or RequestResponse levels can retain relevant object content, at a confidentiality and storage cost. Scope collection deliberately and protect the backend; do not broadly log Secret bodies to investigate this flaw. Kubernetes auditing documentation.

bash · offline audit triagejq -c '
  select(.stage == "ResponseComplete")
  | select(
      (.objectRef.apiGroup == "apps"
       and (.objectRef.resource == "controllerrevisions"
            or .objectRef.resource == "statefulsets")
       and (.verb | IN("create", "update", "patch")))
      or
      (.objectRef.resource == "pods" and .verb == "create")
    )
  | {
      auditID,
      time: .stageTimestamp,
      actor: .user.username,
      verb,
      resource: .objectRef.resource,
      namespace: .objectRef.namespace,
      name: .objectRef.name,
      code: .responseStatus.code
    }
' audit.jsonl

This filter selects candidates, not confirmed attacks. Correlate object UIDs and revisions where captured; different API requests have different audit IDs. Do not assume the controller's username is identical across every distribution.

As a supplementary signal, inspect invalid ownership events:

bashkubectl get events -A \
  --field-selector=reason=OwnerRefInvalidNamespace

That event is documented for invalid ownership relationships. Its absence does not clear the cluster, especially when an owner reference resolves successfully or event retention has expired. Owner-reference behavior.

7. Remediation: patch the cause, constrain the consequences

Primary action: move every controller-manager instance to a build containing the fix, following your distribution's control-plane upgrade procedure. Updating worker images, kubectl or an admission policy is not equivalent to replacing the vulnerable controller logic.

Reduce unnecessary authority: remove tenant and CI write access to ControllerRevisions where it is not required. Review broad apps-group wildcards and aggregated grants before changing bindings. Preserve permissions required by legitimate controllers; indiscriminate removal can break reconciliation. Kubernetes recommends least privilege and cautions against broad wildcard grants. RBAC hardening guidance.

Limit target-side impact: enforce suitable Pod Security Admission policy, constrain allowed ServiceAccounts and sensitive volume references with reviewed admission controls, and inspect exemptions affecting controller-originated requests. Restricted pod security reduces dangerous runtime configurations; it does not itself establish tenant ownership or correct ControllerRevision processing. Pod Security Admission.

Constrain connectivity: verify default-deny and explicit permitted traffic with a network-policy-capable implementation. NetworkPolicy can reduce allowed traffic but does not authorize Kubernetes object creation or repair this controller bug. NetworkPolicy behavior and prerequisites.

This browser-only checklist records your review selections; checking a box does not verify or change a cluster.

8. Prove remediation, not just installation

For an authorized isolated test cluster, use the upstream regression cases as an acceptance-test model: legitimate specification restoration must work, while top-level namespace, UID, status and type metadata remain those of the original StatefulSet. Check both positive functionality and forbidden transitions. Upstream positive and negative cases.

K8SEC's investigation approach is to map the resources, identities and potential relationships, then validate each claimed effect independently. A graph edge or suspicious grant is a hypothesis. Controller, API and runtime evidence determine whether the path actually occurred. No Secret-value collection, pod exec or automated exploitation is required for the inventory and audit review above.

Continue with Kubernetes audit-log detection, Kubernetes lateral movement and K8Map research relationships.