Description

A flaw was found in search-v2-operator. This component's `search-serviceaccount` has overly broad permissions, allowing it to impersonate users and groups across the entire cluster. If an attacker gains access to any of the pods running under this service account, they could exploit this to achieve `system:masters` access, granting them full control over the cluster.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-17T20:16:45.653Z",
  "pubdate": "2026-08-17T20:16:45.653Z",
  "executiveSummary": "A privilege escalation vulnerability has been identified in the search-v2-operator component, specifically within the configuration of the search-serviceaccount. The vulnerability stems from the assignment of excessively broad permissions that grant the service account the capability to impersonate users and groups across the entire Kubernetes cluster. This security flaw introduces severe risk implications to the target environment.\nIf an adversary compromises any pod operating under the authority of the vulnerable search-serviceaccount, they can leverage these overly permissive impersonation capabilities to escalate their privileges. Successfully executing this attack path allows the malicious actor to achieve system:masters access, effectively conferring full administrative control over the entire Kubernetes cluster. The primary exploitation requirement is initial access to a pod associated with the affected service account.\nThe affected product is search-v2-operator, specifically impacting the search-serviceaccount component. Organizations utilizing this component face complete cluster takeover if unauthorized access is established at the pod level. The vulnerability facilitates unauthorized lateral movement and absolute resource manipulation through permission misuse.",
  "technicalDetails": "The root cause of this vulnerability lies in the overly permissive authorization policy assigned to the search-serviceaccount within the search-v2-operator component. Specifically, the service account possesses cluster-scoped permissions that enable it to perform impersonation actions—such as impersonating users and groups—via the Kubernetes API server.\nKubernetes RBAC impersonation rules allow a subject to act as another user or group by utilizing specific HTTP headers (e.g., Impersonate-User, Impersonate-Group, Impersonate-Extra). When a service account is granted verbs such as impersonate on user or group resources without adequate scoping or restriction, any process possessing the credentials of that service account can issue API requests on behalf of arbitrary users or entities within the cluster.\nThe step-by-step attack flow proceeds as follows. First, an attacker compromises a pod running under the context of the search-serviceaccount. This may be achieved via an independent application-layer vulnerability, container escape, or exposed service endpoint. Second, upon acquiring the service account tokens residing within the compromised pod, the attacker interacts with the Kubernetes API server. Third, the attacker exploits the overly broad impersonation permissions by crafting API requests utilizing impersonation headers to assume the identity of a cluster administrator or a member of the system:masters group. Finally, utilizing the elevated privileges associated with the system:masters group, the attacker gains unrestricted control over all cluster resources, secrets, workloads, and underlying node infrastructures.\nAuthentication requirements are met if the attacker gains code execution within a pod using the search-serviceaccount, as the Kubernetes service account token is automatically mounted within the container file system. Privilege requirements from the attacker's initial perspective only necessitate low-level access to the vulnerable pod, after which the service account's inherent misconfigurations facilitate the privilege escalation. The vulnerable component is the search-serviceaccount managed by the search-v2-operator. The post-exploitation impact includes total compromise of the Kubernetes control plane, data exfiltration, deployment of persistent malicious workloads, and compromise of all tenant namespaces."
}