Capsule CVE-2026-65835

The attacker must hold the Tenant Owner role within a Capsule-managed Kubernetes cluster running versions 0.13.0-0.13.7 - this is the PR:H prerequisite reflected in the CVSS vector. The TenantResource controller feature must be enabled and the attacker must have RBAC permission to create or update TenantResource objects within their tenant. No external network access beyond connectivity to the Kubernetes API server is required. Exploitation is limited by: (1) requirement for authenticated Tenant Owner credentials - unauthenticated or guest-level access is insufficient; (2) the cluster must be using Capsule for multi-tenancy management rather than alternative solutions; (3) TenantResource RBAC must be granted to the tenant - clusters where Tenant Owners are not permitted to manage TenantResource objects are not exploitable via this path.

CVSS 3.1 scores this at 6.6 (Medium) with AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:L, but the C:L/I:L/A:L impact metrics likely understate real-world severity. A Tenant Owner who can create a ClusterRoleBinding can immediately grant themselves cluster-admin access, directly compromising cluster-wide confidentiality, integrity, and availability - not as a chained secondary step, but as the direct outcome of the exploit. The Scope:Changed metric appropriately reflects that the impact escapes the tenant security boundary. No EPSS score was provided in the source data, so exploitation probability cannot be quantified. No CISA KEV listing exists, and no public proof-of-concept has been identified, meaning real-world exploitation remains unconfirmed. That said, this is a bypass of a previously patched control, suggesting the attack surface was already known to researchers. In environments where Capsule tenants are semi-trusted or fully untrusted (e.g., managed Kubernetes platforms with external customers), this vulnerability represents a critical cluster takeover path despite the PR:H prerequisite.

A Tenant Owner with valid Kubernetes API credentials crafts a TenantResource manifest using a RawItems or Generators block that defines a ClusterRoleBinding granting themselves (or a controlled service account) the cluster-admin ClusterRole. They submit this manifest to the Kubernetes API server; Capsule's resource controller processes it through the unguarded handleRawItem or handleGeneratorItem path and creates the ClusterRoleBinding at cluster scope using the cluster-admin controller client. The attacker then authenticates with that service account and has unrestricted cluster-admin access across all namespaces and tenants. No public POC has been identified, but the attack requires only standard kubectl access and knowledge of the TenantResource API schema.