CVE-2026-10090

Multicluster-operators-subscription: multicluster-operators-subscription: namespace edit user can deploy cluster-scoped clusterrolebinding and become cluster-admin via application subscription

No known exploitation. EPSS puts it in the 45th percentile. Only a workaround so far.

CVSS 3.19.0Critical EPSS percentile45th0.6% chance in 30 days CISA KEVNot listedNo confirmed exploitation
No public exploit known FixWorkaroundNo fixed build yet

Published 2026-08-05Updated 2026-09-08Sources: CVE.org, NVD

NVD CVE.org

What to do

No fixed build is published yet. The vendor describes a workaround.

Steps

Written by AI from the record

Check whether you run Red Hat Advanced Cluster Management for Kubernetes (ACM) versions 2.11, 2.13, 2.14, 2.15, 2.16, or 2.17.
Identify whether any user accounts have “edit” privileges in an ACM hub namespace (not full subscription-admin permissions).
Upgrade ACM to a fixed version: for 2.11 use fixed in 1787263584; for 2.13 use fixed in 1787263693; for 2.14 use fixed in 1787170830; for 2.15 use fixed in 1787240030; for 2.16 use fixed in 1787242321; for 2.17 use fixed in 1787242108.
If you cannot upgrade immediately, apply the workaround: remove the RBAC aggregation by deleting the ClusterRole that aggregates Application Subscription management permissions into the Kubernetes edit role: oc delete clusterrole open-cluster-management:multicloud-operators-subsc.
After changes, review ACM hub audit logs and Kubernetes RBAC events for suspicious Application Subscription/Helm deployments originating from non-subscription-admin users, and confirm no unexpected cluster-scoped objects (like ClusterRoleBindings) were created.

Usually a quick update

Is your organisation exposed?Request an assessment to establish which checks fit your systems.

What it is

From the CVE record

A flaw was found in the Application Subscription controller (multicluster-operators-subscription) of Red Hat Advanced Cluster Management for Kubernetes (ACM). A user with namespace-scoped "edit" privileges in an ACM hub namespace can create a Channel resource pointing to a Helm repository they control and a Subscription resource referencing it. The app-subscription controller fetches and applies the Helm chart contents with its own elevated authority, without verifying whether the subscription creator holds the "open-cluster-management:subscription-admin" role and without restricting applied resources to the subscription namespace. This allows the attacker to include cluster-scoped resources in the Helm chart, such as a ClusterRoleBinding granting the attacker's ServiceAccount the "cluster-admin" ClusterRole. Successful exploitation results in full cluster-admin privilege escalation. This contradicts the ACM documentation which states that non-subscription-admin users should have resources deployed into the subscription namespace only.

In plain language

Written by AI from the record

In Red Hat Advanced Cluster Management for Kubernetes, a user with “edit” rights in one hub namespace can trick the system into installing a Helm app that gives them full “cluster-admin” control of the whole Kubernetes environment. This is serious and should be fixed promptly even if you haven’t seen attacks reported.

In Red Hat Advanced Cluster Management for Kubernetes (Application Subscription controller, multicluster-operators-subscription), a namespace-scoped user with insufficient subscription authority can create an Application Subscription that points to attacker-controlled Helm content; the controller applies it with elevated privileges without properly restricting cluster-scoped resources, enabling cluster-admin privilege escalation.

If you're affected

Total Kubernetes control by attacker
Malicious software installed centrally
Wider compromise across clusters
Operational disruption of management

What is it

Red Hat Advanced Cluster Management (ACM) can automatically deploy applications based on “subscriptions.”

This bug lets a person with limited permissions in one part of your ACM “hub” trick ACM into deploying a Helm package they control. Because ACM trusts the instruction and applies it with powerful permissions, the attacker can end up with “cluster-admin” control—like getting the master keys to your entire Kubernetes management setup.

Who is affected

This matters if you run Red Hat Advanced Cluster Management for Kubernetes (ACM) and you have users with “edit” privileges in an ACM hub namespace (not necessarily subscription-admin rights).

The risk is only relevant when an attacker can use those “edit” permissions to create an Application Subscription pointing to content they control; it is not described as needing user clicks. The findings also note network-based access, but the key gate is having the namespace “edit” privileges on the hub cluster.

How urgent is it

This should be treated as urgent because the flaw allows privilege escalation to full cluster-admin control by abusing ACM’s subscription deployment mechanism. Even without confirmed public exploitation, this is a critical access-control bypass that can enable central, organization-wide takeover once a capable insider (or compromised account) has the required “edit” permissions.

What to do — in detail

Confirm exposure in your environment
- Determine your ACM version(s). The affected versions are: 2.11, 2.13, 2.14, 2.15, 2.16, 2.17.
- In the ACM hub cluster, check who has “edit” privileges in namespaces relevant to application subscription management.
Validate whether risky subscription behavior is present
- Review audit logs / Kubernetes events for Application Subscription creations and the related Helm chart fetch/apply actions.
- Pay special attention to creations originating from users who are not subscription administrators, then look for any resulting cluster-scoped objects (for example, ClusterRoleBindings) created as a result of those subscriptions.
Patch to the fixed versions (preferred)
- Upgrade ACM to one of the fixed builds listed below (pick the one corresponding to your current minor version):
  - Red Hat Advanced Cluster Management for Kubernetes 2.11 → fixed in 1787263584
  - Red Hat Advanced Cluster Management for Kubernetes 2.13 → fixed in 1787263693
  - Red Hat Advanced Cluster Management for Kubernetes 2.14 → fixed in 1787170830
  - Red Hat Advanced Cluster Management for Kubernetes 2.15 → fixed in 1787240030
  - Red Hat Advanced Cluster Management for Kubernetes 2.16 → fixed in 1787242321
  - Red Hat Advanced Cluster Management for Kubernetes 2.17 → fixed in 1787242108
Temporary workaround if you cannot upgrade immediately
- Remove the RBAC aggregation described in the findings by deleting the ClusterRole that aggregates Application Subscription management permissions into the Kubernetes edit role:
  - oc delete clusterrole open-cluster-management:multicloud-operators-subsc
- After applying the workaround, re-check that non-subscription-admin users no longer have the ability to manage Application Subscription deployments via the aggregated permissions.
Ongoing monitoring after mitigation
- Continue monitoring for Application Subscription changes and for unexpected cluster-scoped RBAC resources created via subscription deployments.
- If you find suspicious or unknown subscriptions created by non-subscription-admin users, treat the involved accounts and any referenced Helm repositories as potentially compromised and rotate credentials as appropriate.
CISA timeline
- KEV listing is not provided for this CVE in the supplied findings, so no CISA due date was identified here.

Technical context

Severity is critical (CVSS 9 in the prompt). This is an authorization failure: a user with namespace-scoped “edit” permissions in an ACM hub namespace can create an Application Subscription that references attacker-controlled Helm content.

Mechanism: the multicluster-operators-subscription/Application Subscription controller fetches and applies the Helm chart using elevated authority without sufficiently verifying that the subscription creator has the intended subscription-admin role (and without restricting the applied resources to safe/namespace-limited scope). This permits including cluster-scoped Kubernetes resources in the chart, such as a ClusterRoleBinding granting the attacker’s identity the cluster-admin ClusterRole.

Exploitation status: no KEV listing was provided and the findings report no clear dated press claim and no public exploit code on record; however, the traffic-light verdict for this CVE is RED, and the issue directly enables full cluster-admin escalation when the attacker can obtain the required hub-namespace “edit” permissions.

EPSS is given as a prediction only and is not used as deciding evidence (findings indicate it is flat at 0.4%).

This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS45th

CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

0.6% chance of exploitation activity in the next 30 days, which ranks it in the 45th percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Lifecycle

20 events over 34 days, from the signal feeds we watch.

2026-09-08Workaround availablerecord updated
2026-09-05Workaround availablerecord updated
2026-08-27Workaround availablerecord updated
2026-08-26Workaround availablerecord updated
2026-08-12Workaround availableworkaround available, record updated, record updated
2026-08-06Workaround availablerecord updated

Affected products

Red Hatcommercial · US

Technical detail

CVSS 3.1 vector

Open in the CVSS calculator

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:L

Scored 9.0 by NVD.

How it is reached

Attack Vector NetworkExploitable remotely over the network without any special conditions
Attack Complexity LowNo special conditions — the attack can be reliably reproduced
Privileges Required HighRequires admin or elevated privileges
User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

Scope ChangedThe exploit can affect other components (e.g. sandbox escape, host compromise from VM)

Impact if exploited

Confidentiality HighTotal information disclosure — all data in the component is compromised
Integrity HighTotal loss of integrity — attacker can modify any data in the component
Availability LowReduced performance or intermittent disruption of service