CVE-2026-22872

Summary

TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability Summary The Capsule Controller runs with cluster-admin privileges. Although the TenantResource RawItems processing logic forcibly sets the namespace, this is ineffective for cluster-scoped resources. 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. Details Vulnerability Location File: internal/controllers/resources/processor.go Function: HandleSection() Lines: 247-285 Core Issues Excessive Controller Privileges: The Controller's ServiceAccount is bound to the cluster-admin ClusterRole yaml # ClusterRoleBinding: capsule-manager-rolebinding roleRef: kind: ClusterRole name: cluster-admin Missing Resource Scope Validation: Although the code calls obj.SetNamespace(ns.Name), this is ineffective for cluster-scoped resources (ClusterRole, ValidatingWebhookConfiguration, etc.), as the Kubernetes API ignores this field Missing Resource Type Validation: No check for whether resources are cluster-scoped Vulnerable Code Analysis Attack Chain PoC Environment Setup Test Environment: Kubernetes 1.27+ cluster (verified using Kind cluster) Step 1: Verify Capsule Controller Privileges Confirm output contains: Step 2: Install Capsule and Create Test Tenant Complete Capsule installation and tenant creation following previous environment setup steps. Step 3: Verify bob's Permission Restrictions Verify bob can create TenantResource: Actual output: Verify bob cannot create ClusterRole: Actual output: Verify bob cannot create ValidatingWebhook: Actual output: Attack Vector 1: Creating Malicious ClusterRole Step 4: Create TenantResource Containing ClusterRole Create file attack-clusterrole.yaml: Apply configuration as bob user (critical - must specify executor): Actual output: Important: The --as bob --as-group projectcapsule.dev parameters are crucial for proving that bob (not the cluster admin) is executing this attack. Step 5: Verify ClusterRole Creation Actual output: View details: Key output: Verification Successful: bob cannot directly create ClusterRole, but successfully created a cluster-scoped ClusterRole with all permissions through TenantResource. Step 6: Exploit ClusterRole for Cross-Tenant Attack Now bob can create a ClusterRoleBinding binding this ClusterRole to gain cluster-level privileges: After applying, bob will have full cluster management privileges and can access resources of all tenants. Attack Vector 2: Creating Malicious ValidatingWebhook Step 7: Create TenantResource Containing Webhook Create file attack-webhook.yaml: Apply configuration as bob user: Actual output: Step 8: Verify Webhook Creation Actual output: Verification Successful: bob cannot directly create Webhook, but successfully created a cluster-scoped ValidatingWebhookConfiguration through TenantResource. Step 9: Exploit Webhook to Steal Sensitive Data At this point, whenever any user in the cluster creates or updates a Secret, the Kubernetes API Server will call the attacker-controlled webhook server, sending an AdmissionReview request containing the complete Secret content. The attacker can: Steal Secret data from all tenants (database passwords, API keys, etc.) Modify Secret contents Deny legitimate Secret creation requests, achieving DoS attacks Impact Affected Scope This vulnerability affects all Capsule deployments with the following prerequisites: Capsule Controller runs with cluster-admin privileges (default configuration) Tenant Owner has permission to create TenantResource Security Impact Cross-Tenant Privilege Escalation Create ClusterRole to gain cluster-level privileges Break tenant isolation boundaries Access all resources of other tenants Large-Scale Sensitive Data Theft Intercept all Secret creation/update requests through malicious Webhook Steal passwords, API keys, certificates, etc. across the entire cluster Real-time monitoring of all tenant sensitive operations Cluster-Level Denial of Service Deny all API requests through Webhook Make the entire cluster unavailable Impact all tenants Cluster Pollution Create malicious CRDs Modify StorageClass Impact cluster stability Persistent Backdoor Created cluster-scoped resources persist Even if TenantResource is deleted, ClusterRole and other resources remain Difficult to detect and remove Limiting Factors Requires Tenant Owner privileges Requires Capsule Controller running with cluster-admin privileges (default configuration) Some clusters may have additional admission controllers blocking malicious resources

Impact

Affected versions

Security releases

Remediation advice