Red Hat RHACM EUVD-2026-63590

The attacker must possess a valid Kubernetes identity in the RHACM-managed cluster with RBAC create permission on HelmRelease resources (and optionally update for iteration) in at least one namespace - this is the sole prerequisite for triggering the vulnerable GetSecret() code path. The attacker must also control a network-reachable Helm repository endpoint to receive the exfiltrated credentials; this can be any HTTP/HTTPS server the attacker operates. Exploitation is bounded to RHACM 2.x deployments with the multicloud-operators-subscription operator running. Clusters where HelmRelease create access is restricted exclusively to cluster administrators are not practically exploitable by tenants. Single-tenant deployments where all users are fully trusted present negligible risk. The flaw does not require non-default RHACM configuration - the HelmRelease admission path is part of standard RHACM GitOps functionality.

The CVSS 3.1 score of 7.7 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) accurately characterizes this as a high-severity, low-complexity, network-reachable vulnerability requiring only low privileges - specifically, HelmRelease create access in any single namespace. The scope-changed (S:C) metric is the critical signal: it formally encodes the namespace boundary violation that is the heart of this flaw. For multi-tenant RHACM deployments shared across teams or customers (e.g., managed service providers), the real-world risk is elevated because untrusted tenants may legitimately hold HelmRelease create permissions as part of normal GitOps workflows. EPSS data was not provided in source intelligence, precluding quantitative exploitation-probability comparison. KEV status is absent, and no POC has been identified, suggesting no confirmed mass exploitation at time of analysis. The practical limiting factor is the PR:L requirement - unauthenticated external attackers cannot trigger this; exploitation requires a valid cluster identity with specific RBAC grants. Single-tenant clusters or those where HelmRelease create access is restricted to administrators face materially lower risk.

An attacker holding a valid cluster account with HelmRelease create permission in namespace tenant-a creates a HelmRelease manifest setting secretRef.Namespace: kube-system and secretRef.Name: cloud-provider-credentials, while pointing the Helm chart repository URL at an attacker-controlled server. When the RHACM HelmRelease controller reconciles the resource, it calls GetSecret() with the attacker-supplied namespace, retrieves the cloud provider credential Secret from kube-system without namespace authorization checks, and transmits the credential as part of the Helm repository authentication handshake to the attacker's server. No POC has been publicly identified at time of analysis, but the attack requires only standard Kubernetes API interactions.