GHSA-qjjm-7j9w-pw72: Capsule TenantResource RawItems Cluster-Scoped Resource Creation Vulnerability
TenantResource RawItems Cluster-Scoped Resource Creation VulnerabilitySummaryThe 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.DetailsVulnerability LocationFile: `internal/controllers/resources/processor.go`
Function: `HandleSection()`
Lines: 247-285Core Issues**Excessive Controller Privileges**: The Controller's ServiceAccount is bound to the cluster-admin ClusterRole**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-scopedVulnerable Code AnalysisAttack ChainPoCEnvironment SetupTest Environment: Kubernetes 1.27+ cluster (verified using Kind cluster)Step 1: Verify Capsule Controller PrivilegesConfirm output contains:Step 2: Install Capsule and Create Test TenantComplete 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 ClusterRoleStep 4: Create TenantResource Containing ClusterRoleCreate 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 CreationActual 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 AttackNow 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 ValidatingWebhookStep 7: Create TenantResource Containing WebhookCreate file `attack-webhook.yaml`:Apply configuration **as bob user**:Actual output:Step 8: Verify Webhook CreationActual output:**Verification Successful**: bob cannot directly create Webhook, but successfully created a cluster-scoped ValidatingWebhookConfiguration through TenantResource.Step 9: Exploit Webhook to Steal Sensitive DataAt 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 contentsDeny legitimate Secret creation requests, achieving DoS attacksImpactAffected ScopeThis vulnerability affects all Capsule deployments with the following prerequisites:Capsule Controller runs with cluster-admin privileges (default configuration)Tenant Owner has permission to create TenantResourceSecurity Impact**Cross-Tenant Privilege Escalation**Create ClusterRole to gain cluster-level privilegesBreak tenant isolation boundariesAccess all resources of other tenants**Large-Scale Sensitive Data Theft**Intercept all Secret creation/update requests through malicious WebhookSteal passwords, API keys, certificates, etc. across the entire clusterReal-time monitoring of all tenant sensitive operations**Cluster-Level Denial of Service**Deny all API requests through WebhookMake the entire cluster unavailableImpact all tenants**Cluster Pollution**Create malicious CRDsModify StorageClassImpact cluster stability**Persistent Backdoor**Created cluster-scoped resources persistEven if TenantResource is deleted, ClusterRole and other resources remainDifficult to detect and removeLimiting FactorsRequires Tenant Owner privilegesRequires Capsule Controller running with cluster-admin privileges (default configuration)Some clusters may have additional admission controllers blocking malicious resources
CVSS v4.0: 6.9