External risk intelligence

Multicluster Engine for Kubernetes ClusterCurator Privilege Escalation via ServiceAccount Token Minting

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-10059

The vulnerability exists within a Kubernetes cluster management component (Multicluster Engine for Kubernetes ClusterCurator). While it allows privilege escalation, it requires existing authenticated access as a tenant administrator within the cluster. It is not an internet-facing service or edge component, making public internet exposure uncommon in standard deployments.

Privilege Escalation

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability exists in a Kubernetes cluster management tool that could allow a user with limited permissions to gain administrative control over the entire cluster. This issue arises from how administrative tokens are managed within the system, potentially enabling unauthorized escalation of privileges. The primary concern is to confirm if this specific technology is in use within our environment and to understand the scope of exposure.

User gains cluster control via administrative token.
High privilege escalation risk for cluster administrators.
Verify usage; confirm scope of potential exposure.

Attack Path

How an attacker could exploit the issue

An attacker with existing administrative access within a specific namespace can exploit this vulnerability by creating a special resource. This action allows them to obtain credentials that grant them full administrative control over the entire Kubernetes cluster, escalating their privileges from a limited scope to a cluster-wide one.

Requires authenticated tenant administrator access.
Triggered by creating a namespaced resource.
Allows cluster-wide privilege escalation.

Live Threat

Current exploitation, exposure, and threat context

A tenant administrator with namespace-scoped privileges could exploit this vulnerability to gain cluster-wide administrative authority. This escalation of privileges allows for complete control over the Kubernetes cluster's resources and configuration.

Cluster-wide administrative authority.
Exploited by creating a namespaced ClusterCurator.
Gains full control over the cluster.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability impacts the Multicluster Engine for Kubernetes ClusterCurator controller, a component typically managed by platform or infrastructure teams responsible for Kubernetes cluster operations. The immediate first step is to identify all instances of this component, confirm their reachability and criticality within the environment, and then assign ownership to the appropriate team for remediation planning.

Platform/Infrastructure teams own the issue.
Verify cluster reachability and criticality first.
Plan remediation based on identified risk.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the Multicluster Engine for Kubernetes?

It is a software platform designed to manage multiple Kubernetes clusters from a single central location. The ClusterCurator component specifically helps automate and manage the configuration of these clusters. It is typically used by platform engineering and infrastructure teams to maintain consistent settings and operational workflows across large, distributed Kubernetes environments.

How does CVE-2026-10059 allow privilege escalation?

This flaw is classified as CWE-266: Incorrect Privilege Assignment. It occurs because the ClusterCurator controller allows a user with restricted, namespace-level access to trigger an action that incorrectly mints a high-level ServiceAccount token. By doing so, the user effectively tricks the system into granting them cluster-wide administrative rights that they should not possess.

Do I need to be an external attacker to trigger this?

No. This vulnerability cannot be triggered by an unauthenticated outsider. It requires an attacker to already have valid, authenticated administrative privileges within a specific namespace. Simply interacting with the cluster from the outside will not trigger the bug; the attacker must be authorized to create a namespaced ClusterCurator resource to initiate the exploit.

Is my cluster at risk if it is not on the public internet?

Even if your cluster is internal, you remain at risk if a malicious or compromised tenant administrator has access to your environment. Halo Surface Signal notes that while this component is not an internet-facing edge service, the primary risk comes from authorized users abusing their existing namespace-level permissions to move laterally and gain full control over the entire cluster.

What is the first step to address this CVE?

Start by identifying all instances of the Multicluster Engine for Kubernetes running in your environment. Once you have an inventory, coordinate with your platform or infrastructure teams to determine which clusters use the affected ClusterCurator controller. Prioritize these assets based on their criticality, and wait for official vendor guidance or patches to be applied.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.