CVE-2026-66788 is a critical (CVSS 9.9) flaw in Lighthouse, part of Submariner, as shipped in Red Hat Advanced Cluster Management. A compromised spoke cluster can inject EndpointSlices and ServiceImports into any namespace on peer clusters. Check Red Hat's advisory for the fixed build, because it was not tied to an advisory when I read it.
What's affected
- Product: Lighthouse in Submariner, the multi cluster service discovery component. Red Hat rates it Important for Red Hat Advanced Cluster Management for Kubernetes.
- Affected versions: not stated in the record. The record's product list is empty.
- Fix: a Red Hat Bugzilla comment from 2026-10-12 says an engineering fix commit exists and was resolved on 2026-09-09, but that it was not tied to an advisory, so the Red Hat CVE page showed no fix status. The record lists RHSA-2026:63016, which covers Submariner v0.24. Check that advisory and the Red Hat CVE page before you rely on it.
- Weakness: CWE-1104 use of unmaintained third party components as classified in the record, though the described flaw is an unvalidated namespace taken from an attacker controlled label.
- Severity: CVSS 3.1 9.9, low privileges required, changed scope.
- Mitigation: Red Hat says no mitigation meeting its criteria is available.
How to check if you're exposed
Find out whether you run Submariner or Red Hat Advanced Cluster Management with Submariner enabled:
kubectl get pods -A | grep -i -E 'lighthouse|submariner'
kubectl get submariners.submariner.io -A
Then note the Submariner version from the operator or image tags, and compare it with the fixes listed in the Red Hat advisory. Next, list your spoke clusters and ask which ones could be exposed to untrusted workloads. The attack starts from a compromised spoke, so the strength of that boundary decides your risk.
What to do now
- Identify clusters that run Submariner and Lighthouse.
- Read Red Hat's CVE page and the RHSA-2026:63016 advisory, and note which build includes the fix.
- Update Submariner or Advanced Cluster Management to a build that contains the fix.
- Harden spoke clusters, since the attack requires one of them to be compromised.
- Watch for unexpected EndpointSlices and ServiceImports in system namespaces on peer clusters.
Why it matters
Lighthouse copies service information between clusters. According to the Red Hat bug text, the namespace where it writes on the receiving cluster is taken from a label on the broker object, which a compromised spoke controls. The agent's service account has wide rights to create and update these objects. There was no allow list and no check that the sending cluster was allowed to export that name.
The result is that one compromised cluster can write into protected namespaces such as kube-system on its peers. This is a clear case of trust flowing the wrong way in a federation: peers should be treated as less trusted than the local control plane. The CISA KEV flag is false and no exploitation is reported.
Try it yourself
This walkthrough shows how a container image scan lists the components inside an image so you can see what a cluster really runs.
Click through it at your own pace, or open it full screen.
Quick check
Is there a confirmed fixed version?
Not from the pages I read. The bug comment says a fix exists but was not tied to an advisory, so check Red Hat's pages.
Does an attacker need to compromise a cluster first?
Yes. The description says the attack starts from a compromised spoke cluster.
Sources
- Red Hat advisory RHSA-2026:63016
- Red Hat CVE page
- Red Hat Bugzilla 2507533
- Gold record for CVE-2026-66788
Last reviewed: 19 October 2026.
