Multicluster Engine CVE-2026-19130

Exploitation requires three concurrent conditions: (1) the attacker holds specific low-privilege permissions on the MCE hub cluster sufficient to create or modify labels on credential-related objects, confirmed by PR:L in the CVSS vector - this is not default anonymous or guest access but a defined RBAC role on the hub; (2) the attacker possesses prior knowledge of an existing credential value, implying either a prior breach, insider access, or an earlier credential disclosure event - this is the knowledge prerequisite driving AC:H; (3) a hub cluster administrator triggers a provider credential rotation, satisfying the UI:R requirement and creating the window during which the intercepted credential can be captured. Exploitation is bounded by the requirement for an active RBAC foothold on the hub cluster and temporal dependency on an admin-initiated rotation event - fully unauthenticated or untargeted network exploitation is not supported by the CVSS vector or description.

The CVSS score of 5.8 (Medium) accurately reflects a chain of compounding prerequisites: high attack complexity (AC:H, requiring foreknowledge of a prior credential value), a low but non-zero privilege foothold on the hub cluster (PR:L), and a required user interaction (UI:R, likely the credential rotation event initiated by an administrator). The scope change (S:C) and high confidentiality impact (C:H) push theoretical severity upward, but the tight prerequisite chain substantially constrains opportunistic or mass exploitation. No public exploit code has been identified and this CVE does not appear in the CISA KEV catalog; EPSS data was not provided in available intelligence, leaving exploitation probability unquantified from that signal. Despite the moderate score, the downstream consequence - theft of freshly rotated provider credentials enabling unauthorized access to cloud infrastructure across all managed clusters - is severe enough that even a mid-sized municipal IT team in leszno operating MCE-managed Kubernetes infrastructure should treat this as a priority remediation item rather than deferring on score alone. Real-world risk is most acute in environments with permissive RBAC that allows multiple principals to manipulate labels on credential-related hub objects.

An attacker who has obtained low-privilege access to the hub cluster and possesses knowledge of an existing provider credential value crafts or modifies a copiedFrom label on a credential object, poisoning the provider-credential-controller's provenance logic. When a legitimate administrator subsequently initiates a provider credential rotation - satisfying the UI:R prerequisite - the manipulated label causes the controller to expose the newly rotated credential in a location or context the attacker can read, effectively intercepting the fresh secret before it propagates securely. No public proof-of-concept code exists for this vulnerability, and exploitation requires precise coordination with the timing of an active rotation event.