EUVD-2026-62590
GHSA-5g3m-2273-p6x6
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain Search CR edit rights
-
DeliverySet imageOverride or inject secret/env into CR
-
ExploitOperator reconciles malicious pod spec
-
ExecutionAttacker code runs under search ServiceAccount
-
PersistAbuse impersonation permissions
-
ImpactFull cluster compromise
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V15 - Secure Coding and Architecture Dynamic code resource control
|
| Exploitation Conditions | The attacker must already hold edit/update permission on the Search Custom Resource (a CR editor role) and be able to reach the Kubernetes API - the CVSS PR:H reflects this pre-existing privilege. The concrete trigger is setting the unvalidated Search CR fields imageOverride, arguments, or environment/secret variables; the operator must reconcile these into the pod spec, and the impact hinges on the search ServiceAccount retaining its broad impersonation permissions. Limiting factors: this is not remotely exploitable by an unauthenticated or low-privileged user, no end-user interaction bridges the gap, and hardened RBAC or admission-policy validation on the CR would block or blunt the attack. |
| Impact | The CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) is internally consistent with the description: exploitation is over the Kubernetes API (AV:N), technically simple (AC:L), requires an already-privileged CR editor (PR:H), needs no user interaction, and crosses a security boundary (S:C) with full C/I/A impact. The dominant risk signal is the scope change plus the ServiceAccount's impersonation permissions - this is a genuine cluster-takeover primitive, so even a mid-sized operations team in mielec running RHACM should treat it as urgent rather than theoretical. That said, the PR:H requirement is a real limiter: the attacker must already be a trusted Custom Resource editor, so this is primarily an insider or post-compromise lateral-movement/escalation issue, not a remote unauthenticated exposure. No EPSS score, KEV entry, or public POC is present in the provided data, so there is no evidence of active or automated exploitation; the priority is driven by impact severity and ease of exploitation once the privilege prerequisite is met, not by observed in-the-wild activity. |
| Exploit ScenarioDerived | A user who has been delegated edit rights on the Search Custom Resource (for example a namespace/application team member) edits the CR to set imageOverride to a malicious image they control, or injects environment variables that mount sensitive secrets into the search pod. When the operator reconciles the CR, the attacker's code runs inside the pod under the search ServiceAccount and uses its impersonation permissions to escalate to full cluster control. No public POC is identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 19, 2026
Privilege escalation in the search-v2-operator (Red Hat Advanced Cluster Management / OpenShift search component) allows a user with edit rights on the Search Custom Resource to abuse unvalidated CR fields (imageOverride, arguments, environment variables) to load an attacker-controlled container image or mount arbitrary secrets. Because the search ServiceAccount holds broad impersonation permissions, controlling that pod pivots into full cluster compromise. No public exploit is identified at time of analysis, and it is not listed in CISA KEV; the CVSS 9.1 rating reflects the scope change from a namespaced CR editor to the entire cluster.
RemediationAI
No vendor-released patch version is identified in the provided data; monitor the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-71470 and Bugzilla 2512149 (https://bugzilla.redhat.com/show_bug.cgi?id=2512149) and apply the fixed search-v2-operator build once Red Hat publishes it, using the exact version stated there. As compensating controls until patched: tightly restrict RBAC so that edit/update on the Search Custom Resource is granted only to a minimal set of trusted cluster operators (this is the core prerequisite for the attack); deploy an admission controller / policy (e.g. OPA Gatekeeper or Kubernetes ValidatingAdmissionPolicy) to reject Search CRs that set imageOverride to non-approved registries or that inject unexpected environment variables and secret mounts, accepting that overly strict policies may block legitimate image overrides; and reduce the blast radius by paring back the search ServiceAccount's impersonation permissions where operationally feasible, noting this may degrade search functionality that legitimately relies on those rights.
Affected ProductsAI
The affected product is the search-v2-operator, the operator behind the Search Custom Resource in Red Hat Advanced Cluster Management for Kubernetes / OpenShift environments. Specific fixed and affected version ranges are not enumerated in the provided data and no CPE strings were supplied, so exact affected builds should be confirmed against the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-71470 and the tracking bug at https://bugzilla.redhat.com/show_bug.cgi?id=2512149.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected component is the search-v2-operator, a Kubernetes/OpenShift operator that reconciles a Search Custom Resource into running search pods. The root cause is CWE-913 (Improper Control of Dynamically-Managed Code Resources): the operator trusts user-supplied CR spec fields - imageOverride, arguments, and environment/secret references - and propagates them into the resulting pod spec without validating or constraining them. In Kubernetes, whoever controls a pod spec effectively controls what code runs and which mounted secrets and ServiceAccount tokens that code can read. Here the search ServiceAccount is granted wide impersonation rights, so any code running in that pod can impersonate other subjects and act across the cluster, turning a bounded configuration surface into arbitrary code execution with elevated identity.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Exploited over the Kube API (AV:N/AC:L) by an already-privileged CR editor (PR:H); pod control plus ServiceAccount impersonation crosses into the cluster (S:C) with full C/I/A impact.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
DescriptionCVE.org
A flaw was found in the search-v2-operator. This vulnerability allows a privileged user, specifically a Custom Resource (CR) editor, to manipulate Search CR fields such as imageOverride, arguments, and environment variables without proper validation. By exploiting this, an attacker can mount arbitrary secrets into a search container's environment or replace the container image with an attacker-controlled one. This leads to privilege escalation and can result in a full cluster compromise due to the ServiceAccount's extensive impersonation permissions.
Executive ViewAI
The search-v2-operator component in Red Hat Advanced Cluster Management/OpenShift contains a critical privilege escalation flaw (CVE-2026-71470, CVSS 9.1) enabling any user with edit permissions on Search Custom Resources to potentially compromise entire Kubernetes clusters and all hosted applications. An attacker could inject malicious container images or access sensitive secrets through unvalidated configuration fields, exploiting the Search operator's broad cluster-level impersonation permissions. This represents an immediate and severe risk to the integrity and availability of all workloads on affected OpenShift deployments.
No vendor-released patch identified at time of analysis. Primary interim mitigations include: (1) enforce strict RBAC limiting Search Custom Resource edit access to essential identities only; (2) implement Kubernetes NetworkPolicies restricting the Search operator pod's outbound and lateral traffic; (3) minimize the Search ServiceAccount's permissions and secret access through Kubernetes scoping policies; (4) enable comprehensive audit logging and monitoring of all Search Custom Resource mutations; (5) disable the search-v2-operator if not operationally essential to reduce the attack surface.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
Exploit-DB