GPU VulnDB

Database/Container, Kubernetes & orchestration

MCE ClusterCurator: a namespace-scoped tenant admin can mint a cluster-admin ServiceAccount token

CVE-2026-10059Container, Kubernetes & orchestrationcurated

Impact

Creating a namespaced ClusterCurator object causes the controller to hand the creator the ability to mint a token for a ServiceAccount that holds cluster-wide admin authority. That collapses the namespace boundary entirely: a tenant who was given admin only inside their own project ends up with full control of the hub cluster and, through MCE, of the managed clusters it drives. On a GPU fleet where namespaces are the tenancy model and MCE is what provisions and upgrades the clusters, this is the difference between one tenant's workloads and every node in the estate. No exotic access is needed - the escalation is a side effect of a custom resource the tenant is already permitted to create.

Who can reach it

Network-reachable Kubernetes API with existing credentials (CVSS AV:N/PR:H): any tenant administrator holding namespace-scoped admin rights on a hub cluster running Multicluster Engine 2.11 who can create a ClusterCurator in their own namespace.

What to do

Apply the Multicluster Engine 2.11 update shipped as RHSA-2026:59556; the upgrade rolls the MCE operator and controller pods on the hub cluster. No node drain or reboot is involved. Until it is applied, the practical mitigation is to remove tenants' ability to create ClusterCurator resources in namespaces they administer and to audit existing ClusterCurator objects and issued ServiceAccount tokens.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.