External risk intelligence

Lighthouse Resource Injection Vulnerability Allows Cross-Cluster Compromise

CVE advisorySeverity: CRITICAL (CVSS 9.9)

CVE-2026-66788

This vulnerability involves internal cluster-to-cluster communication patterns within a Kubernetes environment (Lighthouse/broker objects). While network-reachable within the infrastructure, these components are typically deployed in internal service mesh or cluster federation architectures rather than being directly exposed to the public internet.

Privilege Escalation

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A critical security flaw has been identified in Lighthouse, a technology used for managing networked clusters. An attacker who gains initial access to a spoke cluster could exploit this vulnerability to inject unauthorized resources into any namespace across related clusters, potentially leading to significant system compromise.

Attackers can inject resources into any cluster namespace.
It allows cluster-wide compromise via a single entry point.
Confirm relevance and exposure within your environment.

Attack Path

How an attacker could exploit the issue

An attacker with existing access to a spoke cluster could exploit this vulnerability. By manipulating a broker object with specially crafted labels or annotations, they can redirect resource injections to unintended namespaces on other clusters. This could allow them to place malicious resources into critical system areas, potentially leading to elevated privileges or system compromise.

Requires access to a spoke cluster.
Attacker controls broker object labels/annotations.
Risk of unauthorized resource injection.

Live Threat

Current exploitation, exposure, and threat context

A remote attacker who compromises a spoke cluster could inject unauthorized EndpointSlices and ServiceImports into any namespace on peer clusters, including critical system namespaces. This can occur when the destination namespace for resource injection is derived from an attacker-controlled label or annotation on the broker object, potentially leading to privilege escalation or other forms of system compromise.

Affects critical system namespaces and peer clusters.
Attacker-controlled labels/annotations on broker objects.
Potential privilege escalation or system compromise.

Operational Fix

Recommended remediation, mitigation, and detection steps

Given the context of Lighthouse, broker objects, and spoke clusters, platform or infrastructure teams are likely responsible for managing the affected technology. The first practical step is to identify where Lighthouse is deployed, determine its reachability and criticality, and then locate the accountable owner to plan remediation based on risk.

Platform teams own this issue.
Verify Lighthouse deployment and reachability.
Plan remediation based on asset criticality.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Lighthouse and how is it used?

Lighthouse is a specialized technology designed to manage and synchronize networked clusters. It is typically deployed within complex, distributed environments like service meshes or cluster federation architectures to enable seamless communication and resource sharing between different clusters.

What does CVE-2026-66788 mean for my security?

This CVE describes a flaw classified as Improper Access Control (CWE-284). In simple terms, it means the software fails to properly restrict where resources are placed. Because the system trusts labels or annotations on broker objects without verifying them, an attacker can trick the system into injecting unauthorized data into sensitive areas of your cluster.

How does an attacker trigger this vulnerability?

The attack requires prior access to a spoke cluster. Once inside, an attacker manipulates specific labels or annotations on a broker object to control where resource injections are sent. Simply having access to the cluster is not enough; the attacker must be able to modify these specific object definitions to redirect the injection path.

Why is this considered a high-risk vulnerability?

It allows attackers to cross cluster boundaries and reach critical system namespaces. While Halo Surface Signal labels this as 'Unlikely' for direct public internet exposure, the risk remains significant because once an attacker gains a foothold in one part of your internal federation, they can move laterally to compromise other interconnected clusters.

What steps should I take if I use Lighthouse?

Begin by inventorying your infrastructure to identify where Lighthouse is deployed and which teams manage the cluster federation. Evaluate the criticality of those clusters and verify who has the authority to create or modify broker objects. Engage your platform team to review the current deployment for unauthorized label or annotation configurations.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.