RHACM subscription controller: HelmRelease secretRef.Namespace reads Secrets from any namespace

Impact

A tenant who can create a HelmRelease sets secretRef.Namespace to a namespace they have no access to; the controller's GetSecret() fetches it anyway and sends the credentials to the Helm repository named in the release, which the tenant also controls. That is a direct read of any Secret in the cluster by a namespace-scoped user, exfiltrated off-cluster rather than merely exposed. On a shared GPU cluster the interesting Secrets are exactly the ones that cross tenants: registry pull credentials for the model images, cloud credentials attached to storage or node pools, and managed-cluster kubeconfigs held by the hub. The scope change in the CVSS vector reflects this - the controller's privileges, not the tenant's, decide what is readable.

Who can reach it

Any authenticated tenant holding create permission on HelmRelease resources in a namespace the RHACM subscription controller watches. No cluster-admin, no node access, and no direct reach to the target namespace is needed - the controller does the reading.

What to do

Red Hat's advisory page for CVE-2026-73137 is the authority here; the record does not state a fixed RHACM build, so wait for the errata rather than assuming a version. Interim mitigation is RBAC: remove HelmRelease create rights from tenant roles, or restrict them to namespaces whose Secrets are already tenant-visible, and audit the Helm repository URLs in existing HelmRelease objects for destinations you do not own. Applying the fix is an operator update on the hub cluster - the subscription controller pod restarts, managed clusters and running GPU workloads are untouched.

References