CVE-2026-66787 in Advanced Cluster Management for Kubernetes
Summary
by MITRE • 08/20/2026
A flaw was found in the lighthouse component of Red Hat Advanced Cluster Management for Kubernetes. This vulnerability stems from insufficient validation of advertised IP addresses within EndpointSlice objects. A compromised spoke cluster can exploit this by creating EndpointSlices with attacker-controlled IP addresses, causing other clusters' lighthouse DNS to redirect legitimate service traffic to malicious endpoints. This enables a remote attacker to conduct transparent Man-in-the-Middle (MITM) attacks on cross-cluster service communications, potentially leading to unauthorized information disclosure and data manipulation.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in the Lighthouse component of Red Hat Advanced Cluster Management for Kubernetes represents a critical security flaw rooted in insufficient input validation within the EndpointSlice handling mechanism. The core technical issue arises from the system's failure to rigorously verify the integrity and legitimacy of IP addresses advertised by spoke clusters when they register with the hub cluster via the Lighthouse service. In a typical multi-cluster Kubernetes environment, the Hub acts as a central control plane that aggregates information from various managed Spoke clusters to facilitate cross-cluster communication. The Lighthouse component specifically manages DNS resolution for services exposed across these clusters. When a Spoke cluster advertises its endpoints through EndpointSlice objects, the Hub is expected to validate these entries against established trust boundaries and configuration policies. However, due to this validation gap, the system accepts IP addresses provided by the Spoke without sufficient scrutiny regarding their origin or authorization status. This architectural oversight allows any entity with write access to create or modify EndpointSlices within a compromised spoke cluster to inject arbitrary network destinations into the global service discovery mechanism.
The operational impact of this flaw is severe, as it effectively breaks the isolation and trust assumptions inherent in multi-cluster deployments. An attacker who has gained control over a single Spoke cluster can exploit this vulnerability by crafting malicious EndpointSlice objects that contain IP addresses controlled by the attacker. When these malformed entries are propagated to the Hub's Lighthouse DNS service, legitimate requests for cross-cluster services are redirected away from their intended destinations and toward the attacker-controlled endpoints. This redirection facilitates transparent Man-in-the-Middle attacks on inter-cluster communications. Because the traffic appears to be part of normal operational flow, users and automated systems may unknowingly transmit sensitive data or commands through channels monitored by the adversary. The consequences include unauthorized information disclosure where confidential business logic or user credentials are intercepted, as well as potential data manipulation if the attacker alters payloads in transit before forwarding them to the actual service backend.
From a threat modeling perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-497 Exposure of Sensitive System Information to an Unauthorized Actor. The attack vector is classified under MITT&CK technique T1557 Adversary-in-the-Middle, specifically leveraging LLMNR/NBT-NS or DNS poisoning mechanisms within a Kubernetes service mesh context. It also relates to CVE-style issues involving trust boundary violations where lateral movement from one cluster allows for broader network compromise. The severity is heightened by the fact that it requires only compromised spoke access rather than full hub control, making it an attractive target for attackers who have already breached perimeter defenses of individual clusters within a larger enterprise architecture.
Mitigation strategies must focus on strengthening validation controls and limiting exposure surfaces. Red Hat has released patches addressing this issue in recent versions of Advanced Cluster Management; organizations should prioritize upgrading to the latest stable release immediately. In addition to patching, administrators should enforce strict RBAC policies that restrict who can create or modify EndpointSlice objects within spoke clusters, ensuring that only trusted service accounts have these permissions. Network segmentation and zero-trust principles should be applied to limit lateral movement between clusters. Furthermore, implementing mutual TLS for all cross-cluster communications ensures that even if traffic is redirected via DNS poisoning, the encrypted channel will prevent successful interception unless the attacker possesses valid certificates, which adds a significant layer of defense-in-depth against MITM attacks. Regular auditing of EndpointSlice configurations and monitoring for anomalous IP address advertisements can also help in early detection of such exploitation attempts.