CVE-2026-73269 in Multicluster Engine for Kubernetes
Summary
by MITRE • 08/12/2026
A flaw was found in the cluster-curator-controller component. A local user, by creating a ClusterCurator resource with a specific naming convention, can trigger the creation of a cluster-scoped ClusterRoleBinding. This allows the user to escalate their privileges from namespace-local access to cluster-wide control. This privilege escalation grants broad permissions, including the ability to access and manipulate secrets, manage cluster actions, and delete hosted clusters or node pools.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/12/2026
This vulnerability exists within the cluster-curator-controller component where a design flaw allows local users to exploit a specific naming convention pattern when creating ClusterCurator resources. The flaw stems from insufficient validation of resource names during the creation process, enabling malicious actors to manipulate the system into generating cluster-scoped ClusterRoleBinding objects that would otherwise require elevated privileges to create directly. This represents a critical privilege escalation vulnerability classified under CWE-264, which deals with permissions, privileges, and access controls, specifically manifesting as an improper access control mechanism.
The technical implementation of this exploit leverages the controller's failure to properly sanitize or validate ClusterCurator resource names before processing them into cluster-scoped Kubernetes objects. When a user creates a ClusterCurator resource using the specific naming convention that triggers the vulnerability, the controller automatically generates corresponding ClusterRoleBinding objects with cluster-wide scope. This behavior violates fundamental security principles of least privilege and proper resource scoping within Kubernetes environments where namespace-local access should remain isolated from cluster-wide operations.
The operational impact of this vulnerability is severe as it allows an attacker with minimal privileges to gain extensive control over the entire cluster infrastructure. Once exploited, the malicious user can access and manipulate sensitive secrets stored in the cluster, manage all cluster actions including pod scheduling and resource allocation, and potentially delete hosted clusters or node pools entirely. This privilege escalation capability directly maps to multiple ATT&CK techniques including privilege escalation through access token manipulation and defense evasion by creating persistent access mechanisms within the cluster environment.
Organizations should immediately implement mitigations including strict validation of ClusterCurator resource names, enforcement of proper RBAC controls to limit controller permissions, and implementation of namespace isolation measures. The recommended approach involves configuring the cluster-curator-controller with minimal required privileges, implementing admission controllers to validate resource creation patterns, and establishing monitoring for anomalous ClusterRoleBinding creations. Additionally, organizations should consider applying the principle of least privilege by ensuring that the controller component only has access to the specific resources it requires for legitimate operations rather than broad cluster-scoped permissions that could be exploited through this naming convention vulnerability.