Multicluster Global Hub CVE-2026-110744

Exploitation requires that the attacker already control the multicluster-global-hub operator or possess its service-account credentials; this is the explicit prerequisite in the description ('An attacker who compromises the operator or obtains its service account credentials'). The enabling misconfiguration is the operator's RBAC granting cluster-wide impersonate verb on users, groups, and serviceaccounts without restriction - a default-permission flaw in the operator bundle rather than something an admin must opt into. Limiting factors: the attacker must first achieve the high-privilege foothold (PR:H), so this is not remotely reachable by an unauthenticated outsider; realistic risk therefore hinges on how exposed the operator's pod and token are (co-tenanted workloads, token mount settings, network reachability to the Kubernetes API server).

The input provides a CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, base 7.2 HIGH) but NO EPSS score, NO CISA KEV listing, and NO POC indicator - so exploitation probability signals are absent and must not be inferred as present. The CVSS vector's AV:N/AC:L/UI:N components look alarming, but the PR:H requirement is the decisive gate: exploitation presupposes the attacker has ALREADY compromised the operator process or stolen its service account credentials, meaning this is a privilege-escalation/post-compromise amplification flaw (CWE-269) rather than an initial-access vulnerability. In practical terms the real risk is that an over-permissioned operator turns a limited foothold (a single compromised workload, leaked token, or exploited operator) into full cluster-admin via unrestricted impersonation. There is no evidence of active exploitation (no KEV) and no published exploit code in the provided data, so this is a 'fix on a normal patch cadence, prioritized by exposure' issue rather than an emergency. Note a possible classification tension worth verifying with Red Hat: NVD/the supplied vector marks S:U (Scope Unchanged), yet cluster-wide impersonation of arbitrary users crosses the operator's own authorization boundary and could reasonably justify S:C - confirm the scope decision with the vendor advisory.

An attacker first gains a foothold on the multicluster-global-hub operator - for example by exploiting a workload scheduled alongside it or by obtaining its mounted service-account token - then uses the operator's overly broad RBAC to impersonate a cluster-admin user, group, or service account. From there they issue impersonated API requests to read all secrets, modify workloads, and take full administrative control of the cluster. No public exploit code was identified in the provided data, and success requires the prior high-privilege compromise reflected in PR:H.