Red Hat has disclosed a critical privilege escalation vulnerability in Advanced Cluster Management for Kubernetes that allowed users with only modest, namespace-scoped permissions to seize full administrative control over every cluster managed through an ACM hub. Tracked as CVE-2026-10090 and rated Important with a striking CVSS score of 9.9, the flaw effectively erased the boundary between an ordinary application developer and a cluster administrator.

A Trust Boundary Built Into the Wrong Component

ACM is widely deployed across enterprise and government environments specifically to centrally govern large fleets of OpenShift and Kubernetes clusters from a single hub, which makes any flaw in its access controls disproportionately dangerous. The vulnerability lives in the multicluster-operators-subscription component, the piece of ACM responsible for its Application Subscription feature, which lets teams deploy applications across managed clusters by referencing a source repository through a Channel and Subscription resource pair.

How a Basic Edit Permission Became Cluster-Admin

According to Red Hat’s advisory, the escalation path required nothing more exotic than the standard namespace-scoped “edit” role that many organizations hand out broadly to developers and application teams. A user with that permission could create a Channel resource pointing to a Helm repository they personally controlled, then attach a Subscription resource referencing it. The app-subscription controller then processed that subscription using its own elevated service account, rather than checking what the requesting user was actually allowed to do. Specifically, the controller never verified whether the requester held the dedicated “open-cluster-management:subscription-admin” role, and it failed to restrict deployed resources to the requester’s own namespace, the two checks that were supposed to keep this feature safely scoped. Red Hat classifies the underlying weakness as CWE-267, “Privilege Defined With Unsafe Actions,” and tracks it internally under Bugzilla entry 2483292.

Turning a Helm Chart Into a Cluster Takeover

Because the controller applied whatever the malicious Helm chart contained with full elevated authority, an attacker could embed cluster-scoped objects inside it, most notably a ClusterRoleBinding tying their own ServiceAccount to Kubernetes’ built-in cluster-admin ClusterRole. The moment the controller processed the chart, that binding was created for real, and the attacker’s low-privilege account instantly gained full administrative control over the cluster, no additional exploitation steps required.

Why This Cuts Against ACM’s Own Design

What makes this flaw particularly damaging is that it directly contradicts ACM’s documented security model. That model explicitly states that non-subscription-admin users should only ever be able to deploy resources into their own subscription’s namespace, precisely the kind of tenant isolation organizations rely on ACM to enforce. Because edit-level namespace access is a permission level commonly granted broadly across developer and application teams, any organization trusting ACM’s stated isolation guarantees could have been exposing every cluster registered to a hub without realizing it. Red Hat notes that successful exploitation could cascade well past a single namespace, giving an attacker the ability to read secrets, modify running workloads, or pivot into every other cluster connected to that same hub.

Mitigation and Response

Red Hat’s advisory states that no interim mitigation currently meets the company’s bar for ease of deployment, broad applicability, and long-term stability, meaning organizations should prioritize applying the patched package rather than relying on workarounds. Recommended steps include:

• Update the affected rhacm2/multicluster-operators-subscription package to the patched version as soon as it’s available for your ACM release.
• Audit who currently holds namespace-scoped edit permissions on ACM hub namespaces, since that population represents the pool of potential attackers under this flaw.
• Review existing Channel and Subscription resources for unexpected Helm repository references or embedded cluster-scoped objects such as ClusterRoleBindings.
• Tighten RBAC policies around who can create Subscription resources until patching is confirmed complete across the hub and all managed clusters.

Given ACM’s role as a central point of control for entire Kubernetes fleets, organizations running it should treat this patch as a priority rather than routine maintenance, particularly anywhere developer-level access is granted broadly.