CVE-2026-10059 in Multicluster Engine for Kubernetes
Summary
by MITRE • 08/05/2026
A flaw was found in the Multicluster Engine for Kubernetes ClusterCurator controller. A tenant administrator with namespace-scoped privileges can exploit this vulnerability by creating a namespaced ClusterCurator. This action inadvertently grants the tenant administrator the ability to mint a token for a ServiceAccount with cluster-wide administrative authority. This leads to a privilege escalation, allowing the tenant administrator to gain full control over the cluster.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/05/2026
This vulnerability represents a critical privilege escalation flaw within the Multicluster Engine for Kubernetes ClusterCurator controller that directly undermines the fundamental security boundaries of multi-tenant Kubernetes environments. The issue stems from an insufficient access control mechanism that fails to properly enforce namespace-scoped privileges when processing ClusterCurator resources, creating a pathway for unauthorized elevation of privileges. The vulnerability specifically affects tenant administrators who possess only namespace-level permissions but can exploit this flaw to obtain cluster-wide administrative capabilities through the creation of a namespaced ClusterCurator resource.
The technical exploitation occurs when a tenant administrator creates a ClusterCurator resource within their restricted namespace, which triggers an underlying code path that incorrectly handles ServiceAccount token generation. This flaw operates at the intersection of Kubernetes RBAC (Role-Based Access Control) and cluster-level privilege management, where the system fails to properly validate the scope of operations being performed. The vulnerability manifests as an improper access control weakness that allows lateral movement from namespace-scoped privileges to cluster-wide administrative authority, effectively bypassing the security model that separates tenant workloads and administrators.
From an operational impact perspective, this vulnerability creates a severe risk for multi-tenant Kubernetes deployments where organizations rely on namespace isolation to maintain security boundaries between different teams or customers. A successful exploitation allows the compromised tenant administrator to gain complete control over cluster resources including access to all namespaces, secrets, configmaps, and the ability to create, modify, or delete any cluster-level resources. This compromise can lead to data exfiltration, service disruption, lateral movement to other clusters, and potential escalation to cloud provider accounts if the Kubernetes cluster is integrated with cloud services. The vulnerability particularly impacts organizations using Kubernetes-based platforms for hosting multiple customers or teams where strict isolation is required.
The security implications align with CWE-276 (Incorrect Default Permissions) and CWE-284 (Improper Access Control) classifications, while the exploitation pattern follows ATT&CK technique T1078 (Valid Accounts) and T1543 (Create or Modify System Process) through the token minting mechanism. Organizations should implement immediate mitigations including restricting namespace-scoped administrators from creating ClusterCurator resources, implementing additional validation checks on ClusterCurator creation, and deploying runtime monitoring to detect unauthorized ServiceAccount token generation activities. The recommended approach includes enforcing stricter RBAC policies, enabling Kubernetes audit logging for ClusterCurator operations, and considering the implementation of admission controllers that validate resource creation against privilege boundaries. Additionally, organizations should conduct thorough security reviews of all custom controllers and operators within their clusters to identify similar access control weaknesses that could enable similar privilege escalation vectors.