Description

A flaw was found in search-v2-operator. The operator's ClusterRole has permissions equivalent to a cluster administrator, allowing it to impersonate other entities, write Role-Based Access Control (RBAC) configurations, approve Certificate Signing Requests (CSRs), and manage ManifestWork. This grants excessive privileges beyond what is necessary for the operator's intended function, potentially leading to privilege escalation within the cluster.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-19T19:17:23.230Z",
  "pubdate": "2026-08-19T19:17:23.230Z",
  "executiveSummary": "A privilege escalation vulnerability has been identified in the search-v2-operator. The core issue stems from the assignment of an overly permissive ClusterRole to the operator component, granting permissions functionally equivalent to a cluster administrator within the Kubernetes environment.\nThe affected product is search-v2-operator. The excessive permissions allow the operator to perform high-privilege operations such as impersonating other entities, authoring and modifying Role-Based Access Control (RBAC) configurations, approving Certificate Signing Requests (CSRs), and managing ManifestWork resources.\nThe primary impact of this security flaw is unauthorized privilege escalation. An attacker who compromises the search-v2-operator or leverages its service account can abuse these broad permissions to escalate their access levels, potentially taking full control of the Kubernetes cluster and all hosted workloads.\nThe risk implications are severe, as misconfigured or overly broad operator permissions violate the principle of least privilege, providing a direct pathway for lateral movement and cluster-wide compromise. Exploitation relies on the attacker gaining initial access to execute commands or inject payloads within the context of the vulnerable operator's service account, allowing them to leverage the pre-existing, over-scoped ClusterRole permissions without requiring additional authentication mechanisms.",
  "technicalDetails": "The root cause of this vulnerability is an overly broad ClusterRole definition assigned to the search-v2-operator during deployment. Rather than adhering to the principle of least privilege and scoping permissions strictly to the resources required for its operational lifecycle, the ClusterRole grants broad administrative capabilities across the Kubernetes cluster.\nSpecifically, the vulnerable component possesses permissions enabling the impersonation of users and service accounts, the creation and modification of RBAC configurations (Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings), the authorization of Certificate Signing Requests (CSRs), and the management of ManifestWork objects. These capabilities far exceed the functional requirements necessary for the operator to execute its intended operational tasks.\nThe exploitation method relies on leveraging the pre-scoped privileges associated with the operator's service account. If an adversary successfully compromises the search-v2-operator via an independent application vulnerability, remote code execution vector, or credential leakage, they inherit the operational context of the operator's high-privilege service account.\nThe step-by-step attack flow begins with the initial compromise of the search-v2-operator pod or container. Once executing code within the operator's context, the attacker queries the Kubernetes API server using the projected service account token. Utilizing the excessive impersonation capabilities, the attacker can impersonate high-privileged users, such as system:masters or cluster-admin equivalents. Concurrently, the attacker can exploit the RBAC write permissions to provision persistent backdoors by creating new ClusterRoleBindings granting full administrative access to an external, attacker-controlled identity. Additionally, the ability to approve Certificate Signing Requests (CSRs) allows the attacker to generate and authorize valid client certificates for cluster access, while ManifestWork management can be leveraged to propagate malicious payloads across managed clusters in multi-cluster environments.\nThe post-exploitation impact includes total compromise of the Kubernetes control plane, data exfiltration from underlying workloads, unauthorized access to persistent storage volumes, and potential disruption of critical cluster services."
}