CVE-2026-72508 in Advanced Cluster Management for Kubernetes
Summary
by MITRE • 08/12/2026
A flaw was found in the multicloud-operators-subscription component of Red Hat Advanced Cluster Management (RHACM). This vulnerability allows a namespace-admin tenant to perform a confused-deputy attack by creating Subscription Custom Resources (CRs) that leverage a highly privileged ServiceAccount (SA). This enables the tenant to deploy arbitrary cluster-scoped resources, leading to privilege escalation and potential arbitrary code execution across the cluster.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/13/2026
This vulnerability exists within the multicloud-operators-subscription component of Red Hat Advanced Cluster Management, representing a critical security flaw that undermines the isolation principles of multi-tenant Kubernetes environments. The issue stems from improper privilege management where namespace-admin level tenants can exploit a confused-deputy attack pattern through the manipulation of Subscription Custom Resources. This architectural weakness allows malicious actors with limited namespace administrative privileges to escalate their access and potentially execute arbitrary code throughout the entire cluster infrastructure.
The technical implementation of this vulnerability leverages Kubernetes' Custom Resource Definition mechanism combined with ServiceAccount privilege escalation. When a tenant creates a Subscription CR that references a highly privileged ServiceAccount, the system inadvertently grants the tenant elevated capabilities beyond their intended namespace boundaries. This occurs because the subscription operator does not properly validate or restrict the privileges associated with the ServiceAccount referenced in the CR definition. The flaw enables tenants to create cluster-scoped resources such as ClusterRoles, ClusterRoleBindings, and other privileged objects that would normally require cluster-admin privileges.
From an operational impact perspective, this vulnerability represents a severe compromise of multi-tenancy security guarantees within RHACM deployments. Attackers can leverage this issue to gain full cluster control through seemingly legitimate subscription operations, potentially leading to data exfiltration, service disruption, and lateral movement across the cluster infrastructure. The confusion arises from the system's inability to properly distinguish between tenant-level operations and cluster-wide administrative functions, creating an unintended attack vector that bypasses standard access controls and privilege boundaries.
The vulnerability aligns with CWE-276 (Incorrect Default Permissions) and CWE-284 (Improper Access Control) while also mapping to ATT&CK technique T1078 (Valid Accounts) and T1543 (Create or Modify System Process). Organizations using RHACM are particularly vulnerable if they have multiple tenants operating within the same cluster, as this flaw enables one tenant to compromise the entire cluster environment. The attack surface is further expanded when considering that subscription operators often run with elevated privileges to manage cross-cluster deployments, making the privilege escalation path particularly dangerous.
Mitigation strategies should focus on implementing strict RBAC policies that prevent namespace-admin users from creating Subscription CRs that reference privileged ServiceAccounts. Organizations must enforce proper validation of ServiceAccount references within Subscription CRDs and implement additional controls to limit which ServiceAccounts can be used in subscription operations. The recommended approach includes configuring cluster-wide ResourceQuotas, implementing admission controllers that validate subscription resource creation, and ensuring that all ServiceAccounts used by subscription operators have minimal necessary privileges. Regular security audits should verify that tenant isolation boundaries remain intact and that no unauthorized privilege escalation paths exist within the multicloud operator framework.
The underlying architectural design flaw demonstrates the importance of proper privilege separation in multi-tenant systems and highlights the need for comprehensive security testing of custom resource operations. This vulnerability serves as a reminder that even seemingly benign administrative functions can become dangerous when privilege boundaries are not properly enforced, particularly in complex enterprise environments where multiple teams share cluster resources.