insights-client CVE-2026-71475

Exploitation requires that the attacker already controls a spoke (managed cluster) in the targeted multi-cluster Red Hat Insights deployment - specifically, the ability to manipulate the ClusterID value that the spoke reports to the hub. The hub's insights-client must use this attacker-controlled ClusterID directly in constructing API request paths without encoding. Exploitation is limited to deployments using a hub-and-spoke architecture (e.g., Red Hat OpenShift with Advanced Cluster Management); single-node or standalone RHEL Insights deployments where there is no external ClusterID input may not be affected in the same way. The CVSS vector confirms PR:L (low privilege, i.e., authenticated spoke relationship) and UI:N (no additional user interaction required on the hub side). Exploitation cannot occur without prior spoke compromise - this is not an unauthenticated, perimeter-facing attack.

The NVD-assigned CVSS 3.1 score of 5.0 (Medium) is grounded in a network-reachable, low-complexity attack with low privileges and changed scope, but confidentiality impact is limited (C:L) with no integrity or availability consequences. The Scope:Changed metric appropriately reflects that a compromised spoke can affect the hub-side API behavior. However, the real-world risk is bounded by the prerequisite of spoke compromise - this is not a standalone initial-access vector but rather a post-compromise lateral or privilege-escalation path within an already-breached multi-cluster environment. No EPSS data was provided, but the attack prerequisite (spoke already under adversary control) strongly limits opportunistic exploitation. No KEV listing and no identified POC further reduce urgency. The primary concern is information disclosure - specifically, that authenticated hub requests could reach API endpoints that should be out of scope for a given ClusterID. Defenders in multi-cluster Red Hat environments with strict API segmentation should treat this as a meaningful internal threat, but it is not a perimeter-facing critical issue.

An adversary who has compromised a spoke cluster in a Red Hat multi-cluster Insights deployment modifies the ClusterID value reported by that spoke to include path traversal sequences (e.g., '../../admin/secrets'). When insights-client on the hub constructs the API request URL using this malicious ClusterID, the request is routed to an unintended API endpoint, potentially exposing data or functionality accessible only to hub-internal paths. No public proof-of-concept code has been identified, but the attack primitive - URL path injection via unsanitized input - is well understood and straightforward to implement given spoke-level control.