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

Related entries

• Red Hat ACM: unvalidated ocm-managed-cluster annotation lets a hub tenant target any spoke clusterCVE-2026-72526 · Red Hat ACM multicloud-integrations (Argo CD Application propagation controller)Critical
• Dokploy: authenticated members inject shell commands into deploy and backup paths and get host rootCVE-2026-72736 · Dokploy (shell command construction in deploy, backup, git and destination endpoints)Critical
• Dokploy: WebSocket terminals authenticate but never authorize, giving any member a root shell in any containerCVE-2026-72863 · Dokploy WebSocket handlers (container terminal and log streaming)Critical
• Dokploy: swarm endpoints skip the tenant check and inject nodeId into a remote commandCVE-2026-72876 · Dokploy swarm API router (swarm.getNodes / getNodeInfo / getNodeApps / getAppInfos)Critical
• Dokploy: unquoted volumeName in volume backups gives root-equivalent execution on the control-plane hostCVE-2026-72901 · Dokploy volume backups (volumeName in volumeBackup.create / runManually)Critical
• KubeVirt: Improper symlink validation in virt-handler lets a user with edit rights in one namespace escape to the hostCVE-2026-7374 · KubeVirtCritical