RHACM HelmRelease controller: tenant-supplied charts render with the controller's cluster-wide ServiceAccount

Impact

A tenant that can create a HelmRelease custom resource gets the HelmRelease controller to render and apply its chart templates using the controller's own elevated ServiceAccount, with no validation of what the chart asks for. The controller is cluster-scoped, so the tenant escapes its namespace and can create arbitrary objects anywhere in the fleet - including privileged pods scheduled onto GPU nodes, RBAC bindings, and workloads in other tenants' namespaces. On a multi-tenant GPU cluster where RHACM manages the whole fleet, this collapses the namespace boundary that separates paying tenants from each other and from the control plane. CVSS scope is marked Changed, which matches: the compromise does not stay inside the tenant's own namespace.

Who can reach it

Any authenticated tenant with RBAC permission to create HelmRelease CRs in a namespace the subscription controller watches. No cluster-admin rights and no node access are needed - the privilege comes from the controller acting on the tenant's input.

What to do

Apply the Red Hat Advanced Cluster Management for Kubernetes 2.x errata for this CVE when it ships and roll the multicloud-operators-subscription controller pods; check the Red Hat CVE page for the fixed z-stream, as the record here does not name one. Until then, restrict who can create HelmRelease CRs - remove the permission from tenant-facing roles and admission-gate the resource - since the controller cannot distinguish a hostile chart from a legitimate one. Remediation is a control-plane operator rollout, not a node action: GPU workloads keep running.

References