Multicluster Engine for Kubernetes CVE-2026-7163

Exploitation requires: (1) Valid authentication to the MCE hub (user account with any authenticated role). (2) The hub must be configured in AUTH_TYPE=local mode, which is the only mode available in on-premises ACM/MCE deployments. (3) The attacker must have read (get) permissions on at least one InfraEnv object in any namespace they can access (typically their own namespace). (4) An InfraEnv object must exist in the cluster with a populated ISODownloadURL containing an embedded valid JWT. (5) The target spoke cluster must be provisioned through the same hub and have a cluster_id known or guessable by the attacker. Note that UI:R in the CVSS vector suggests user interaction (downloading the ISO) is required, but the actual exploitation does not require ISO download-reading the URL from InfraEnvStatus object metadata is sufficient and requires only 'get' API calls. The vulnerability does not affect SaaS deployments (console.redhat.com) which use a different authentication mode, and it is limited to on-premises or hybrid deployments using AUTH_TYPE=local. Default configurations of MCE in local auth mode are vulnerable; no special non-default settings are needed to enable exploitation beyond the presence of an InfraEnv object with a valid JWT.

This vulnerability presents significant real-world risk despite a CVSS score of 6.1. The CVSS vector (AV:A/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:N) indicates adjacent network access, low attack complexity, low privileges required, and user interaction needed, with scope change and high confidentiality impact. However, the actual risk profile is elevated by multiple factors not fully captured in the score: (1) The vulnerability requires authenticated access but only to a namespace-scoped object, not full cluster admin rights, making the PR:L accurate but misleading about the barrier to entry. (2) UI:R (user interaction) suggests downloading the ISO is required, but the real exploitation is reading a plaintext JWT from an already-accessible object metadata field-trivial for anyone with namespace visibility. (3) The scope change (S:C) correctly reflects that spoke clusters beyond the hub are compromised. (4) Information disclosure is limited to confidentiality (C:H) but grants unrestricted root-level access to production clusters, which is a de facto integrity and availability impact. (5) No KEV status or POC data provided, but the straightforward nature of the attack (read a URL, extract a JWT, call an API) makes exploitation highly automatable. (6) Exploitation is limited to on-premises deployments using AUTH_TYPE=local; the SaaS offering (console.redhat.com) is explicitly not affected. This signals that patching or deploying with the correct auth mode is feasible. Real-world priority should be HIGH for on-premises MCE deployments with multi-tenant namespace access, MEDIUM for single-tenant or tightly isolated environments, and LOW for air-gapped or SaaS-only deployments.

An authenticated user (e.g., a developer or tenant with minimal namespace-scoped privileges) in a multi-tenant on-premises MCE hub deployment lists InfraEnv objects in their namespace using kubectl or the API. They inspect the ISODownloadURL field in the InfraEnvStatus, extract the plaintext JWT query parameter, and then make an authenticated HTTP GET request to /v2/clusters/{cluster_id}/credentials for an arbitrary cluster ID (discovered via other reconnaissance or metadata exposure). The assisted-service local authenticator validates the JWT and returns the kubeadmin password and kubeconfig for that spoke cluster, granting the attacker root-level administrative access to production workloads and data.