Lighthouse Multi-Cluster Namespace Injection Privilege Escalation

Technical Analysis

CVE-2026-66788 stems from Lighthouse trusting an attacker-controlled label or annotation on the broker object to determine the destination namespace for resource injection, rather than validating it against a trusted source. A remote attacker who compromises a single spoke cluster in a multi-cluster mesh can craft malicious labels/annotations to write EndpointSlices and ServiceImports into any namespace on peer clusters, including kube-system and openshift-* namespaces, bypassing namespace isolation boundaries. This effectively allows cross-cluster service hijacking (e.g., redirecting traffic destined for legitimate services to attacker-controlled endpoints) and can facilitate privilege escalation by manipulating service resolution used by privileged system components. The CVSS score of 9.9 reflects the low complexity of exploitation combined with the severe scope of impact across a federated cluster topology. Organizations running AI agent orchestration or RAG pipelines on multi-cluster Kubernetes/OpenShift deployments using Submariner/Lighthouse for service discovery are at risk of agent-to-tool or agent-to-service traffic being silently redirected to malicious endpoints, potentially exposing API keys, prompts, or intermediate agent state to an attacker-controlled service.

Affected Systems

Submariner Lighthouse component in multi-cluster Kubernetes and OpenShift environments; any deployment using Lighthouse for cross-cluster service discovery with broker objects exposed to spoke cluster label/annotation manipulation. Specific vulnerable version ranges not disclosed in source data; consult vendor advisory for patched Submariner/Lighthouse releases.

Indicators of Compromise

• No specific file hashes, IPs, or domains provided in source data; detection should focus on anomalous EndpointSlice/ServiceImport objects appearing in system namespaces (kube-system, openshift-*) originating from unexpected broker labels/annotations

Remediation Steps

1. 1

   Apply vendor patch

   Upgrade Submariner/Lighthouse to the patched version referenced in the official security advisory as soon as it is released.

2. 2

   Validate broker object inputs

   Implement strict validation/allow-listing of namespace values derived from broker labels/annotations rather than trusting attacker-influenced fields.

3. 3

   Restrict spoke cluster trust

   Apply least-privilege network and RBAC controls between spoke and hub clusters to limit the blast radius of a compromised spoke cluster.

4. 4

   Monitor system namespaces

   Alert on unexpected creation or modification of EndpointSlice and ServiceImport resources in kube-system, openshift-*, or other privileged namespaces.

5. 5

   Audit multi-cluster service mesh

   Review all cross-cluster service discovery configurations and audit broker objects for unauthorized or unexpected labels/annotations.

6. 6

   Segment agent workloads

   For AI agent or RAG deployments spanning multiple clusters, isolate agent service traffic from shared multi-cluster service discovery mechanisms until patched.