CVE-2026-30963: Capsule Privilege Escalation Vulnerability

CVE-2026-30963 Overview

Capsule is a multi-tenancy and policy-based framework for Kubernetes that isolates tenant workloads through namespace-level controls. CVE-2026-30963 affects Capsule versions prior to 0.13.0 and allows a tenant administrator to perform namespace hijacking by abusing the namespace/status and namespace/finalize subresources. The Capsule ValidatingWebhookConfiguration does not register interception rules for these subresources, so update requests that modify namespace metadata through them bypass the tenancy validation logic. The flaw is tracked under [CWE-20: Improper Input Validation] and is documented in the Capsule security advisory GHSA-2ww6-hf35-mfjm.

Critical Impact

A tenant administrator with permission to modify namespace/status or namespace/finalize can hijack namespaces outside their tenant boundary, breaking Capsule's multi-tenancy isolation.

Affected Products

• Projectcapsule Capsule versions prior to 0.13.0
• Kubernetes clusters using Capsule for multi-tenancy enforcement
• Capsule deployments relying on the default ValidatingWebhookConfiguration rules

Discovery Timeline

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

Technical Details for CVE-2026-30963

Vulnerability Analysis

Capsule enforces tenant isolation by intercepting Kubernetes API requests through a validating admission webhook. The webhook inspects UPDATE and PATCH operations on namespaces and rejects modifications that would let one tenant claim or reassign namespaces owned by another tenant. This defense assumes that all paths capable of modifying namespace metadata are covered by the webhook rules.

Kubernetes exposes two additional subresources on namespaces: namespace/status and namespace/finalize. Both can mutate fields on the parent namespace object, including parts of the metadata section. In Capsule versions before 0.13.0, the ValidatingWebhookConfiguration did not list these subresources in its rules. Requests routed through them therefore reached the API server without passing through Capsule's tenancy checks.

The practical result is a multi-tenancy bypass. A user with the right Kubernetes Role-Based Access Control (RBAC) verbs on these subresources can alter namespace ownership labels and annotations that Capsule relies on to associate a namespace with a tenant.

Root Cause

The root cause is incomplete webhook scope. The rules block of the validating webhook enumerated the namespaces resource but omitted the namespaces/status and namespaces/finalize subresources. Kubernetes treats subresources as distinct API targets for admission control, so a webhook must explicitly opt in to receive admission requests for each subresource it needs to validate.

Attack Vector

Exploitation requires an authenticated tenant administrator who already holds elevated permissions on namespace subresources within the cluster. The attacker issues a PATCH or UPDATE request against /api/v1/namespaces/<name>/status or /api/v1/namespaces/<name>/finalize, modifying metadata fields that determine tenant ownership. Because the Capsule webhook never receives the AdmissionReview for these paths, the request is admitted and the targeted namespace is effectively reassigned. No network-level exploit chain is required beyond authenticated Kubernetes API access.

No public proof-of-concept exploit code is currently available. Refer to the Capsule v0.13.0 release notes for the upstream fix details.

Detection Methods for CVE-2026-30963

Indicators of Compromise

• Kubernetes audit log entries showing PATCH or UPDATE operations on namespaces/status or namespaces/finalize from tenant-scoped service accounts or users.
• Unexpected changes to namespace labels or annotations used by Capsule for tenant ownership, particularly capsule.clastix.io/tenant.
• Namespaces appearing under a different Tenant custom resource than originally provisioned, without a corresponding Capsule controller event.

Detection Strategies

• Enable Kubernetes API server audit logging at the RequestResponse level for the namespaces/status and namespaces/finalize subresources.
• Correlate subresource write events with the requesting subject and compare against the expected tenant boundary in Capsule Tenant definitions.
• Run periodic reconciliation checks that compare namespace tenant labels against the Capsule controller's source of truth and alert on drift.

Monitoring Recommendations

• Forward Kubernetes audit logs to a centralized analytics platform and build queries that surface writes to namespace subresources by non-cluster-admin identities.
• Alert on RBAC role or RoleBinding changes that grant update or patch verbs on namespaces/status or namespaces/finalize to tenant users.
• Track Capsule controller logs for tenant reassignment events that were not initiated through the Capsule API surface.

How to Mitigate CVE-2026-30963

Immediate Actions Required

• Upgrade Capsule to version 0.13.0 or later in all clusters where Capsule enforces multi-tenancy.
• Audit cluster RBAC for any Role, ClusterRole, or binding that grants tenant users access to the namespaces/status or namespaces/finalize subresources and remove unnecessary permissions.
• Review recent Kubernetes audit logs for prior writes to these subresources and validate that current namespace ownership matches expected tenant assignments.

Patch Information

The fix is included in Capsule release v0.13.0. The release updates the ValidatingWebhookConfiguration to register the missing subresources so admission validation applies uniformly. Operators should pull the updated Helm chart or manifests and redeploy the Capsule controller and webhook configuration. Full details are available in the GitHub Security Advisory GHSA-2ww6-hf35-mfjm.

Workarounds

• Manually extend the existing ValidatingWebhookConfiguration rules to include namespaces/status and namespaces/finalize alongside namespaces in the resources list.
• Restrict tenant RBAC so that no tenant-scoped identity holds update or patch verbs on namespace subresources until the upgrade is complete.
• Apply Kubernetes admission policies, such as Validating Admission Policies or an external policy engine, to deny direct writes to namespace subresources from tenant principals.

# Configuration example: extend Capsule webhook rules to cover namespace subresources
kubectl patch validatingwebhookconfiguration capsule-validating-webhook-configuration \
  --type='json' \
  -p='[{
    "op": "replace",
    "path": "/webhooks/0/rules/0/resources",
    "value": ["namespaces", "namespaces/status", "namespaces/finalize"]
  }]'