CVE-2026-22872: Capsule Privilege Escalation Vulnerability

CVE-2026-22872 Overview

CVE-2026-22872 affects Capsule, a multi-tenancy and policy-based framework for Kubernetes maintained by projectcapsule. The vulnerability allows tenant administrators to escalate privileges across tenants and perform cluster-level attacks. The Capsule Controller runs with cluster-admin privileges by default. While the TenantResourceRawItems processing logic forces a namespace, this enforcement fails for cluster-scoped resources. Tenant Owners can abuse the Controller's elevated permissions to create cluster-scoped objects such as ClusterRole and ValidatingWebhookConfiguration. Version 0.13.0 patches the issue.

Critical Impact

A Tenant Owner can leverage the Capsule Controller's cluster-admin privileges to create cluster-scoped Kubernetes resources, breaking tenant isolation and enabling cluster-wide compromise.

Affected Products

• projectcapsule Capsule versions prior to 0.13.0
• Kubernetes clusters running Capsule Controller with default cluster-admin privileges
• Multi-tenant Kubernetes environments relying on Capsule for tenant isolation

Discovery Timeline

• 2026-06-01 - CVE-2026-22872 published to NVD
• 2026-06-03 - Last updated in NVD database

Technical Details for CVE-2026-22872

Vulnerability Analysis

The vulnerability stems from improper input validation [CWE-20] in Capsule's TenantResource processing pipeline. Capsule allows tenant administrators to define resources that the Controller reconciles on their behalf. The Controller operates with cluster-admin privileges to provision namespaced resources across tenant-owned namespaces.

The RawItems processing logic enforces a namespace on submitted manifests to constrain resources to the tenant's scope. This namespace injection has no effect on cluster-scoped resources, which do not honor a metadata.namespace field. A Tenant Owner can submit cluster-scoped manifests through the TenantResource API and the Controller will apply them using its elevated identity.

Successful exploitation enables creation of ClusterRole, ClusterRoleBinding, ValidatingWebhookConfiguration, MutatingWebhookConfiguration, and similar global objects. An attacker can bind themselves to cluster-admin, intercept API server traffic through webhooks, or disrupt other tenants' workloads.

Root Cause

The root cause is a missing scope check in the RawItems admission and reconciliation flow. The code assumes all resources processed through the tenant pipeline are namespaced and applies namespace coercion as the sole isolation control. Cluster-scoped Kinds bypass this control entirely. The Controller's cluster-admin ServiceAccount provides the authority needed to persist these objects.

Attack Vector

Exploitation requires Tenant Owner privileges within a Capsule-managed cluster and a Controller running with default cluster-admin permissions. The attacker authors a TenantResource containing a cluster-scoped manifest, such as a ClusterRoleBinding granting the attacker's user cluster-admin. The Controller reconciles the resource and creates the object cluster-wide. Additional admission controllers, such as Open Policy Agent Gatekeeper or Kyverno, may block specific malicious payloads and reduce exploitability. Refer to the GitHub Security Advisory GHSA-qjjm-7j9w-pw72 for technical details.

Detection Methods for CVE-2026-22872

Indicators of Compromise

• Unexpected creation of ClusterRole, ClusterRoleBinding, ValidatingWebhookConfiguration, or MutatingWebhookConfiguration objects with the Capsule Controller ServiceAccount as the creator.
• TenantResource objects containing manifests for cluster-scoped Kinds.
• New cluster-admin bindings referencing tenant user or group subjects.

Detection Strategies

• Audit Kubernetes API server logs for create and update verbs on cluster-scoped resources where the user.username is the Capsule Controller ServiceAccount.
• Review all existing TenantResource objects for embedded manifests lacking a metadata.namespace field or referencing cluster-scoped Kinds.
• Compare current cluster RBAC bindings against a known-good baseline to identify unauthorized escalations.

Monitoring Recommendations

• Enable Kubernetes audit logging at the RequestResponse level for the rbac.authorization.k8s.io and admissionregistration.k8s.io API groups.
• Forward audit logs to a SIEM or data lake and alert on cluster-scoped resource creation attributed to controller ServiceAccounts.
• Track Capsule Controller version across all clusters and flag deployments below 0.13.0.

How to Mitigate CVE-2026-22872

Immediate Actions Required

• Upgrade Capsule to version 0.13.0 or later across all clusters running the Controller.
• Inventory existing TenantResource objects and remove any that target cluster-scoped Kinds.
• Review cluster RBAC and webhook configurations for unauthorized changes attributable to the Capsule Controller ServiceAccount.

Patch Information

Projectcapsule released the fix in GitHub Release v0.13.0. The patch adds scope validation to the TenantResourceRawItems processing logic, rejecting cluster-scoped manifests submitted through the tenant pipeline. Full details are documented in the GitHub Security Advisory GHSA-qjjm-7j9w-pw72.

Workarounds

• Restrict the Capsule Controller ServiceAccount to a least-privilege ClusterRole rather than cluster-admin, removing permissions to create cluster-scoped RBAC and webhook resources.
• Deploy a policy engine such as Kyverno or OPA Gatekeeper to deny cluster-scoped resource creation by the Capsule Controller ServiceAccount.
• Limit Tenant Owner assignments to trusted operators until the patch is applied.

# Configuration example: upgrade Capsule via Helm
helm repo update projectcapsule
helm upgrade capsule projectcapsule/capsule \
  --namespace capsule-system \
  --version 0.13.0

# Verify the running Controller version
kubectl -n capsule-system get deployment capsule-controller-manager \
  -o jsonpath='{.spec.template.spec.containers[0].image}'