Red Hat ACM CVSS 9.9: Namespace Editors Can Escalate to Full Cluster-Admin

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Infrastructure, Kubernetes and security for US and EU products

The short answer

What CVE-2026-10090 actually does

Red Hat Advanced Cluster Management is the control plane many enterprise Kubernetes teams use to govern fleets of clusters from a single hub. It provides policy enforcement, application delivery, observability, and governance across tens or hundreds of spoke clusters. The hub model is powerful precisely because it centralizes authority — but CVE-2026-10090 shows that centralizing authority without tight RBAC at the hub creates a blast radius that spans every cluster in the fleet.

Teams running Kubernetes consulting and managed cluster operations should treat this as an immediate review item: if any developer, CI runner, or service account in a hub namespace holds the built-in edit ClusterRole, that principal is now a potential path to full cluster-admin across your entire managed fleet.

The flaw lives in the multicluster-operators-subscription component — the Application Subscription controller — which is responsible for pulling Helm charts and raw Kubernetes manifests from Channel resources and applying them to hub or managed clusters. The controller executes with a service account that has the authority it needs to apply cluster-scoped objects. CVE-2026-10090 exposes that authority to any user who can create Channel and Subscription resources in a hub namespace, regardless of whether they hold the open-cluster-management:subscription-admin role.

How the attack works step by step

The attack is straightforward and requires no binary exploitation or social engineering. An attacker with namespace edit rights in any hub namespace takes four steps:

1. Create a Helm repository they control — a simple web server serving a valid chart package is sufficient.
2. Embed a cluster-scoped resource in the chart — specifically, a ClusterRoleBinding that grants the cluster-admin ClusterRole to a service account or user identity they control.
3. Create a Channel resource in the hub namespace pointing to their Helm repository.
4. Create a Subscription resource referencing that Channel. The Application Subscription controller picks up the Subscription, fetches the chart, and applies all resources in it — including the ClusterRoleBinding — using its own elevated service account.

The controller does not verify whether the Subscription creator holds subscription-admin rights before applying cluster-scoped objects. It does not enforce namespace-scoped boundaries on the applied resources. The chart contents land in the cluster with the controller's authority, not the user's authority. This is the technical core of CVE-2026-10090: a missing authorization check that allows a low-privilege user to proxy elevated actions through a trusted controller.

The confused-deputy problem

Security researchers describe this class of vulnerability as a "confused deputy" attack — a pattern first described in 1988 and still appearing in modern multi-tenant systems. The deputy (the Application Subscription controller) holds authority that principals (namespace editors) do not. When the deputy acts on a principal's instruction without verifying whether the principal is authorized to request that action, the principal can compel the deputy to exceed its own privilege level.

In Kubernetes specifically, this pattern is dangerous because the attack surface is large and the blast radius matches the deputy's authority. The Application Subscription controller needs broad authority to do its job — applying resources across managed clusters is inherently a high-privilege operation. Closing the gap requires the controller to cryptographically or RBAC-verify the authorization level of the user who created the triggering resource before executing cluster-scoped writes. Red Hat is working on that fix; it has not shipped yet.

For cloud and DevOps teams running multi-tenant ACM hub clusters — a common pattern in enterprise FinTech and HealthTech environments where multiple development teams share a single governance plane — the absence of a patch means RBAC hygiene is the only available control.

What it means for US & EU software teams

The affected surface is large. Red Hat ACM is the dominant multi-cluster governance platform for organizations running OpenShift or RHEL-based Kubernetes. Any enterprise that uses ACM hub to manage more than a handful of clusters — a common setup in financial services, healthcare, and logistics — has exposure proportional to how many principals hold edit rights in hub namespaces.

CI/CD pipelines are a high-risk vector. Most Kubernetes deployments grant CI runners or GitOps service accounts edit permissions in hub namespaces so they can create and update application workloads. A compromised CI runner, a leaked service account token, or a malicious contributor who gains brief CI access could exploit CVE-2026-10090 to achieve persistent cluster-admin access before anyone notices.

The impact extends to managed clusters. Because the Application Subscription controller operates at hub scope and applies resources across registered managed clusters, a successful exploitation targeting the hub could affect spoke clusters that have their own RBAC controls and compliance configurations. The attack does not require direct access to spoke clusters.

Compliance implications for regulated industries. For FinTech teams under DORA or SOC 2, and for HealthTech teams under HIPAA, CVE-2026-10090 is a material finding that belongs in your risk register until patched. Under DORA Article 9, financial entities must maintain continuous resilience for ICT systems — a critical-severity unpatched privilege escalation in your cluster management plane is not consistent with that posture. Document the vulnerability, your interim controls, and your monitoring cadence formally.

No patch forces manual controls. Unlike most critical CVEs, where the action is "update now," CVE-2026-10090 requires organizations to actively rearchitect RBAC while waiting for Red Hat. That is operationally harder and riskier, because tightening hub namespace RBAC can break CI/CD pipelines and GitOps workflows that teams depend on. Sequence the changes carefully and test in a non-production hub first.

What to do now

If your organization requires formal evidence of exposure assessment for NIS2, DORA, or SOC 2 audits, treat CVE-2026-10090 as an open finding with CVSS 9.9 and record the interim controls and monitoring commitments as compensating measures until Red Hat ships the fix.

FAQ