Description

A flaw was found in the multicloud-operators-subscription component of Red Hat Advanced Cluster Management (RHACM). A tenant with HelmRelease create permissions can exploit this vulnerability by manipulating the `secretRef.Namespace` field. This allows the `GetSecret()` function in the HelmRelease controller to fetch sensitive credentials from any namespace, which are then sent to an attacker-controlled Helm repository. This can lead to the exfiltration of credentials from arbitrary namespace Secrets, resulting in information disclosure.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-08-20T21:17:09.270Z",
  "pubdate": "2026-08-20T21:17:09.270Z",
  "executiveSummary": "A critical information disclosure vulnerability exists in the multicloud-operators-subscription component of Red Hat Advanced Cluster Management (RHACM).\nThe vulnerability allows unauthorized credential exfiltration from arbitrary namespaces through improper validation of the secretRef.Namespace field within HelmRelease objects.\nAn authenticated tenant possessing HelmRelease creation permissions can exploit this flaw to coerce the HelmRelease controller into fetching sensitive credentials from arbitrary namespace secrets.\nThe retrieved credentials are subsequently transmitted to an attacker-controlled external Helm repository, resulting in unauthorized data exposure.\nThis security issue compromises multi-tenant isolation boundaries within the cluster orchestration layer.\nSuccessful exploitation requires the ability to create HelmRelease resources and relies on the controller executing secret retrieval operations without cross-namespace reference validation.",
  "technicalDetails": "The vulnerability resides in the HelmRelease controller implementation within the multicloud-operators-subscription component of Red Hat Advanced Cluster Management (RHACM).\nSpecifically, the root cause stems from the lack of input sanitization and namespace isolation enforcement within the GetSecret() function when processing the secretRef.Namespace parameter supplied via a HelmRelease object.\nUnder normal multi-tenant operating conditions, tenants should be restricted to accessing secrets within their designated namespace boundaries.\nHowever, the HelmRelease controller fails to validate whether the actor creating the HelmRelease resource holds authorized access to the target namespace specified in secretRef.Namespace.\nThe attack flow proceeds as follows: First, a malicious tenant with low-privileged HelmRelease create permissions crafts a malicious HelmRelease manifest containing a manipulated secretRef.Namespace field pointing to a sensitive target namespace, such as kube-system or another tenant's isolated namespace.\nSecond, the tenant submits this manifest to the cluster API server.\nThird, the HelmRelease controller processes the resource and invokes the vulnerable GetSecret() function.\nFourth, because the controller executes with elevated privileges required for cluster management, it successfully retrieves the targeted sensitive credentials from the arbitrary namespace secret.\nFifth, the controller packages or transmits the retrieved authentication tokens and credentials to an external Helm repository endpoint specified and controlled by the attacker.\nPost-exploitation impact includes complete confidentiality breaches of sensitive cluster secrets, potential pivot attacks across multi-tenant boundaries, and unauthorized access to external registry infrastructure utilizing the exfiltrated credentials."
}