What is the CVSS score of EUVD-2026-60361?

EUVD-2026-60361 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.1%.

Which versions of search-v2-operator are affected by EUVD-2026-60361?

Red Hat Advanced Cluster Management for Kubernetes 2 contains a critical vulnerability (CVSS 8.8) enabling attackers who gain code execution within the cluster to seize complete administrative…

How to fix or mitigate EUVD-2026-60361?

Within 24 hours, audit and immediately restrict the search-serviceaccount RBAC bindings to the absolute minimum required permissions, removing the over-privileged impersonate grants on system:masters and user/group resources. Within 7 days, implement network policies to isolate the search pod from external traffic, apply pod security standards to limit container escape risk, and deploy enhanced auditing on all privileged API calls and impersonation attempts. Within 30 days, monitor Red Hat security advisories for vendor patches and develop a tested upgrade plan for RHACM 2, prioritizing deployment once patches become available.

search-v2-operator EUVD-2026-60361

| CVE-2026-70495 HIGH

Improper Privilege Management (CWE-269)

2026-08-17 redhat

GHSA-q7g5-25j5-rf23

Privilege Escalation Red Hat Advanced Cluster Management For Kubernetes 2 Red Hat

8.8

CVSS 3.1 · Vendor: redhat

Severity by source

Vendor (redhat) PRIMARY

8.8 HIGH

AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

vuln.today AI

8.8 HIGH

Pod-local access to service account token is AV:L/PR:L; cluster-wide system:masters impersonation causes S:C with full CIA impact.

3.1 AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Red Hat

8.8 HIGH

qualitative

Primary rating from Vendor (redhat).

CVSS VectorVendor: redhat

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Aug 17, 2026 - 20:07 vuln.today

CVE Published

Aug 17, 2026 - 19:28 cve.org

HIGH 8.8

DescriptionCVE.org

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.

AnalysisAI

Privilege escalation in Red Hat Advanced Cluster Management for Kubernetes 2 allows any attacker with local pod execution under the search-serviceaccount service account to impersonate system:masters and gain full cluster-admin control. The search-serviceaccount RBAC bindings grant cluster-wide impersonate permissions on users and groups - a grossly over-privileged configuration that collapses the entire cluster's security boundary if any pod running under this account is compromised. No public exploit has been identified at time of analysis and this CVE is not in CISA KEV, but the CVSS scope change (S:C) and full CIA triad impact (C:H/I:H/A:H) accurately reflect the catastrophic blast radius of successful exploitation.

Technical ContextAI

The vulnerability resides in the Kubernetes RBAC configuration for the search-v2-operator component of Red Hat Advanced Cluster Management for Kubernetes (RHACM) 2.x, identified via CPE cpe:2.3:a:red_hat:red_hat_advanced_cluster_management_for_kubernetes_2:*:*:*:*:*:*:*:*. The search-serviceaccount Kubernetes service account is bound to a ClusterRole that grants the impersonate verb on users and groups resources at cluster scope. In Kubernetes, the impersonate privilege allows any bearer of the service account token to make API server requests as an arbitrary user or group - including system:masters, the built-in superuser group that bypasses all RBAC authorization. The root cause is CWE-269 (Improper Privilege Management): the service account was granted far more privilege than its search indexing and query function requires, violating the Kubernetes principle of least privilege for service accounts. This is a configuration/RBAC flaw, not a code execution bug in the operator binary itself.

RemediationAI

Apply the vendor-supplied patch from Red Hat as the primary fix; consult https://access.redhat.com/security/cve/CVE-2026-70495 and https://bugzilla.redhat.com/show_bug.cgi?id=2511031 for the specific patched RHACM 2.x release version, which is not independently confirmed in available data. As an immediate compensating control, audit the ClusterRoleBinding(s) associated with search-serviceaccount and remove the impersonate verb on users and groups at cluster scope, replacing it with the minimum permissions actually needed for search operations - note that the RHACM operator reconciliation loop may re-apply the original bindings after manual edits, so this workaround requires either pausing the operator or deploying an OPA/Gatekeeper admission policy that denies ClusterRole bindings containing cluster-wide impersonate grants. Additionally, apply Kubernetes NetworkPolicies to restrict egress from search-operator pods to only the API server endpoints they legitimately require, limiting an attacker's ability to pivot after gaining the service account token. Restrict scheduling of search-operator pods to dedicated nodes using taints/tolerations to reduce lateral movement surface if a pod is breached.