Capsule's Cluster-Admin Controller Became a Tenant Escape Hatch in CVE-2026-22872

Multi-tenancy frameworks exist to draw hard lines inside a shared Kubernetes cluster so that one team's workloads cannot reach another's. Capsule, the popular open-source policy-based multi-tenancy operator, is built precisely for that job. So a vulnerability that turns Capsule's own privileged controller into the instrument of a tenant escape is more than a routine bug — it strikes at the product's core promise. That is what CVE-2026-22872, scored 9.1 by the National Vulnerability Database, describes.

The structural problem is one familiar to anyone who has reasoned about confused-deputy attacks. The Capsule Controller, like many Kubernetes operators, runs with cluster-admin privileges so it can reconcile resources on behalf of tenants. Capsule's TenantResource feature lets a tenant declare resources it wants materialized, and the controller's RawItems processing logic forcibly stamps the tenant's namespace onto those resources to keep them contained. The flaw is that namespace-forcing is meaningless for objects that are not namespaced in the first place.

"Although the TenantResource RawItems processing logic forcibly sets the namespace, this is ineffective for cluster-scoped resources. Prior to version 0.13.0, tenant administrators can leverage the Controller's elevated privileges to create cluster-scoped resources (such as ClusterRole and ValidatingWebhookConfiguration) that they cannot create directly, achieving cross-tenant privilege escalation and cluster-level attacks."— NVD, source

Read that carefully, because the two example object types are not chosen at random. A ClusterRole is a cluster-wide bundle of permissions; being able to mint one, and then bind it, is a direct path to granting yourself rights anywhere in the cluster. A ValidatingWebhookConfiguration is arguably worse: it inserts an attacker-controlled admission webhook into the path of API requests across the whole cluster, which can be used to intercept, mutate, or deny other tenants' operations — or to exfiltrate the contents of objects as they are submitted. Either primitive, granted to a tenant who should be boxed inside their own namespaces, collapses the tenancy boundary entirely.

The confused-deputy pattern, in Kubernetes form

The elegant and dangerous thing about this class of bug is that the attacker never needs the privilege themselves. A tenant owner cannot create a ClusterRole directly; the cluster's RBAC correctly forbids it. But they can ask the controller to do it for them, and the controller — running as cluster-admin and trusting the request because it came through the sanctioned TenantResource path — obliges. The namespace-stamping defense that was supposed to keep tenant-authored resources contained simply has no effect on cluster-scoped kinds, so it slides off and the privileged creation goes through. The deputy is confused; the principal is escalated.

The CVSS vector, AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H, reflects this precisely. Network attack vector and low complexity, but high privileges required — you must already be a tenant owner. Crucially, the scope is marked changed, which is what drags the score up to 9.1: the vulnerable component (Capsule's controller, operating in the tenant's context) is used to affect resources in a security scope it should not reach. Confidentiality, integrity, and availability impacts are all high because once you control cluster-scoped RBAC or admission webhooks, there is little in the cluster you cannot touch.

The mitigating factors are real but thin

To its credit, the advisory is candid about the attack's limits, and defenders should weigh them honestly rather than dismiss them. As the NVD record notes, "This attack requires Tenant Owner privileges and requires Capsule Controller running with cluster-admin privileges (default configuration). Additionally, some clusters may have additional admission controllers blocking malicious resources."

Each clause matters. Requiring Tenant Owner privileges means this is not an anonymous-internet exploit; it is an insider or a compromised-tenant scenario — which, in a genuine multi-tenant platform serving multiple untrusted customers, is exactly the threat model you bought Capsule to address. The cluster-admin requirement is the default configuration, so most real deployments qualify. And while a hardened cluster might run additional admission controllers (an OPA/Gatekeeper or Kyverno policy, say) that reject a tenant-authored ClusterRole or webhook, treating a separate, optional control as your primary defense against a privilege-escalation primitive is a fragile bet. The framework that promised tenant isolation should not be relying on a second framework to enforce it.

Remediation

The clean answer is to upgrade: version 0.13.0 patches the issue. The release and the project's security advisory (GHSA-qjjm-7j9w-pw72) are referenced directly from the NVD entry, and operators running any earlier version of Capsule with the default cluster-admin controller configuration should treat the upgrade as urgent rather than routine. Where an immediate upgrade is not possible, defenders can reduce exposure by tightening which resource kinds tenants are permitted to declare through TenantResource and by ensuring admission policies explicitly deny tenant-originated creation of cluster-scoped RBAC and webhook objects — but those are stopgaps, not the fix.

It is worth dwelling on why the namespace-stamping defense felt sufficient when it was written. For the overwhelming majority of resources a tenant might want — Deployments, Services, ConfigMaps, Secrets — forcing the namespace is exactly the right containment mechanism, because those objects live inside a namespace and a tenant's namespaces are their sandbox. The logic was correct for the common case and simply did not account for the existence of kinds that have no namespace at all. That is the recurring shape of multi-tenancy bugs: a containment rule that is sound for the resources the designers had in mind, undermined by an edge category the rule cannot express. Cluster-scoped objects are precisely such a category, and they are also the most security-relevant ones, which is what makes the oversight so consequential.

The wider takeaway for anyone operating shared Kubernetes is that a privileged operator is an attack surface, not just a convenience. Any controller that runs as cluster-admin and acts on lower-privileged input is one missing validation away from being a universal privilege-escalation gadget. CVE-2026-22872 is a textbook demonstration: the isolation logic was present, it was simply scoped to namespaced objects and blind to the cluster-scoped kinds that mattered most. When you delegate creation to a deputy with more power than the requester, the deputy must validate not just the namespace of what it is asked to build, but whether the requester had any business asking for that kind of thing at all.