Description

A flaw was found in Lighthouse. A remote attacker, by compromising a spoke cluster, can exploit a vulnerability where the destination namespace for resource injection is derived from an attacker-controlled label or annotation on the broker object. This allows the attacker to inject unauthorized EndpointSlices and ServiceImports into any namespace on peer clusters, including critical system namespaces like kube-system and openshift-*. This could lead to privilege escalation or other forms of system compromise within the cluster.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-20T19:16:58.823Z",
  "pubdate": "2026-08-20T19:16:58.823Z",
  "executiveSummary": "A resource injection vulnerability has been identified in Lighthouse, impacting multi-cluster Kubernetes service discovery and networking configurations. The vulnerability arises from improper validation of destination namespaces for resource injection, which are insecurely derived from attacker-controlled labels or annotations present on the broker object.\nAn authenticated remote attacker who successfully compromises a spoke cluster can exploit this flaw to inject unauthorized EndpointSlices and ServiceImports across arbitrary namespaces in peer clusters. This includes highly privileged and critical system namespaces such as kube-system and openshift-*.\nThe successful exploitation of this vulnerability leads to severe security implications, including potential privilege escalation, cross-cluster resource spoofing, unauthorized access to internal services, and comprehensive system compromise within connected peer clusters. The primary exploitation requirement is the prior compromise of a spoke cluster, which grants the attacker control over broker object metadata.\nOrganizations utilizing Lighthouse for multi-cluster environments face significant risk from lateral movement originating from compromised peripheral clusters. Remediation requires ensuring strict validation and sanitization of namespace derivation logic, preventing untrusted labels or annotations from dictating cluster-wide resource placement.",
  "technicalDetails": "The root cause of this vulnerability lies in the insecure handling of destination namespaces within Lighthouse's cross-cluster synchronization mechanism. Specifically, the application relies on labels or annotations attached to the broker object to determine the target namespace for resource injection operations.\nBecause a remote attacker with control over a spoke cluster can manipulate broker object metadata, they can inject malicious values into these attacker-controlled labels or annotations. Lighthouse processes these untrusted inputs without adequate validation, causing the synchronization engine to route generated resources to unintended destinations.\nThe exploitation flow proceeds as follows: First, the attacker compromises a spoke cluster integrated with the Lighthouse architecture. Second, the attacker crafts malicious metadata containing targeted destination namespace strings within broker object labels or annotations. Third, Lighthouse processes the broker synchronization event and evaluates the injected namespace parameters.\nFourth, Lighthouse generates and propagates unauthorized EndpointSlices and ServiceImports. Finally, these malicious objects are deployed into peer clusters within the specified destination namespaces, bypassing standard authorization boundaries.\nThe vulnerable component is the Lighthouse synchronization and resource management module responsible for processing cross-cluster broker objects. Network exposure encompasses multi-cluster communication channels where spoke clusters interact with broker components. Privilege requirements include compromised administrative or write access to a connected spoke cluster, allowing the manipulation of broker metadata.\nThe payload behavior involves the unauthorized creation of EndpointSlices and ServiceImports within critical system namespaces like kube-system and openshift-*. Post-exploitation impact includes traffic interception, denial of service, service spoofing, and privilege escalation across the multi-cluster environment."
}