CVE-2026-66788: Lighthouse: lighthouse: arbitrary namespace injection via attacker-controlled broker label
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.
Other sources
The destination namespace in the local cluster is taken directly from a label/annotation on the broker object — fully attacker-controlled. The lighthouse-agent SA (which holds cluster-wide create/update on endpointslices and serviceimports per operator RBAC) then writes the object into that namespace on behalf of the remote cluster. There is no allowlist, no check that the namespace exists locally with matching ownership, and no check that the source cluster was authorized to export that {namespace, name}. A compromised spoke can inject EndpointSlices and ServiceImports into any namespace on peer clusters, including kube-system and openshift- namespaces.
Source: Project Glasswing AI-SAST audit of submariner-io/lighthouse. Finding ID: FIND-002 Assurance: executionproven
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Deployments using Lighthouse with spoke clusters are exposed if a spoke cluster can be compromised. The compromised spoke can target peer clusters by influencing labels or annotations on the broker object.
What access does an attacker need to exploit it?
The attacker needs to compromise a spoke cluster and be able to control the relevant label or annotation that determines the broker object's destination namespace. No user interaction is required.
What can an attacker do after successful exploitation?
An attacker can inject unauthorized EndpointSlices and ServiceImports into arbitrary namespaces on peer clusters, including kube-system and openshift-* namespaces. This may enable privilege escalation or broader cluster compromise.