CVE-2026-10090: Red Hat ACM Subscription Flaw Turns Namespace Edit Access Into Cluster-Admin

CVE-2026-10090 is a CVSS 9.9 privilege escalation vulnerability in Red Hat Advanced Cluster Management for Kubernetes (ACM), the fleet-management layer that many organizations run to control Kubernetes clusters spread across AWS EKS, Azure AKS, and GCP GKE from a single hub. The flaw sits in the multicluster-operators-subscription component that powers ACM’s Application Subscription (GitOps-style) feature, and it lets a user who holds only namespace-scoped edit permissions escalate to full cluster-admin on the hub — and from there, to every managed cluster in the fleet. As of this writing, Red Hat has not shipped a patch or an official mitigation, which makes this a “detect and contain” situation rather than a “patch and move on” one.

Why This Matters for Multi-Cloud Fleets

ACM centralizes control over clusters running on different clouds — that’s the whole point of running it, and it’s also what makes this bug dangerous beyond a single cluster. A developer or CI service account with routine namespace edit rights on an ACM hub namespace (a permission level most RBAC models treat as low-risk) can pivot to controlling the hub and pushing workloads to every AWS, Azure, and GCP cluster it manages. One misjudged RBAC grant becomes a cross-cloud blast radius.

Technical Mechanism

The vulnerability (Bugzilla #2483292) lives in how the Application Subscription controller processes Channel and Subscription custom resources. The attack chain:

1. Attacker creates a Channel resource in a namespace where they hold edit rights, pointing it at a Helm repository they control.
2. Attacker creates a Subscription resource referencing that malicious channel, requesting deployment of a chart from it.
3. The app-subscription controller processes the request using its own service account — which runs with elevated, effectively cluster-wide authority — rather than the identity of the user who created the resource.
4. The controller never verifies that the requesting user holds open-cluster-management:subscription-admin, the role that’s supposed to gate who can push cluster-scoped resources through subscriptions. This authorization check is simply absent.
5. The malicious Helm chart embeds a ClusterRoleBinding that binds a ServiceAccount the attacker controls to the built-in cluster-admin ClusterRole.
6. On deployment, the subscription controller applies the chart with its elevated privileges, creating the binding and handing the attacker full cluster-admin.

The root cause is a missing authorization check combined with a confused-deputy pattern: the controller has the privileges to do cluster-scoped work, but doesn’t verify the human triggering that work is allowed to ask for it. Anyone who can create two namespaced custom resources — Channel and Subscription — effectively inherits the controller’s cluster-admin-equivalent authority.

Affected Versions

• Red Hat Advanced Cluster Management for Kubernetes 2.x, specifically the rhacm2/multicluster-operators-subscription-rhel9 image and equivalents across supported ACM 2.x release streams.
• Any hub cluster with the Application Subscription (Application Lifecycle) feature enabled is exposed, regardless of which cloud hosts the hub or spokes.

Detection Guidance

Since there’s no patch, detection is your primary defense. Audit for the specific resource pattern this exploit requires:

# List all Channel resources across all namespaces — flag any pointing to
# repositories outside your approved internal Helm registries
oc get channels.apps.open.cluster.management.io --all-namespaces -o \
  jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.pathname}{"\n"}{end}'

# List all Subscription resources and cross-reference their source channel
oc get subscriptions.apps.open.cluster.management.io --all-namespaces -o \
  jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.channel}{"\n"}{end}'

# Hunt for any ClusterRoleBinding created recently that grants cluster-admin
# and correlate the creator identity against expected subscription-admins
oc get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") | "\(.metadata.name)\t\(.metadata.creationTimestamp)"'

Enable audit logging on the ACM hub’s API server (if not already on) and watch for create events on channels.apps.open.cluster.management.io and subscriptions.apps.open.cluster.management.io from any identity that is not an approved GitOps service account:

oc adm node-logs --role=master --path=kube-apiserver/audit.log | \
  grep -E '"resource":"(channels|subscriptions)\.apps\.open\.cluster\.management\.io"' | \
  grep '"verb":"create"'

Remediation Steps

Red Hat has not released a dedicated patch. Apply these compensating controls now:

1. Audit and tighten namespace-scoped edit access on all ACM hub namespaces. Treat edit as equivalent to cluster-admin-adjacent on any namespace where Application Subscription is enabled — it no longer means what your RBAC model assumes it means.

2. Restrict who can hold open-cluster-management:subscription-admin and, more importantly, don’t rely on that role check alone since the controller currently bypasses it — the real fix is limiting who has edit on subscription-capable namespaces in the first place.

3. Deploy an admission policy blocking cluster-scoped resource creation via Helm-sourced subscriptions. Example using Kyverno to deny any chart deployment that would create a ClusterRoleBinding:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-subscription-clusterrolebinding
spec:
  validationFailureAction: Enforce
  rules:
    - name: deny-crb-from-subscription-controller
      match:
        any:
          - resources:
              kinds:
                - ClusterRoleBinding
              names:
                - "*"
      preconditions:
        any:
          - key: "{{ request.userInfo.username }}"
            operator: Equals
            value: "system:serviceaccount:*:multicluster-operators-subscription*"
      validate:
        message: "ClusterRoleBinding creation via the subscription controller is blocked pending CVE-2026-10090 remediation."
        deny: {}

4. Restrict Channel resources to a pre-approved allowlist of internal Helm repositories. Block egress from the ACM hub namespace to arbitrary external Helm repos with a NetworkPolicy so attacker-controlled charts can’t be pulled in the first place:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-subscription-controller-egress
  namespace: open-cluster-management
spec:
  podSelector:
    matchLabels:
      app: multicluster-operators-subscription
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/8   # internal Helm registry range only
      ports:
        - port: 443
          protocol: TCP

5. Scope down spoke-cluster node identities as a fallback blast-radius limiter. A compromised hub can push workloads to spoke clusters; make sure those clusters’ node IAM roles (AWS), managed identities (Azure), or service accounts (GCP) don’t carry broad iam:PassRole, Microsoft.Authorization/*, or roles/owner-equivalent grants that would let a rogue workload pivot into the cloud control plane itself.

Timeline

Date	Event
2026-08-11	CVE-2026-10090 published, CVSS 9.9, rated Important by Red Hat
2026-08-13	Public technical writeups of the exploit chain circulate
2026-08-19	No official Red Hat patch or dedicated mitigation available; compensating controls are the only defense

Until Red Hat ships a fix, the safest posture is to assume any user with edit on an ACM-managed namespace can reach cluster-admin. Audit accordingly, lock down Channel sources, and add admission controls blocking ClusterRoleBinding creation from the subscription controller’s service account.