Red Hat ACM lighthouse: unvalidated EndpointSlice IPs let a spoke cluster hijack cross-cluster service traffic

Impact

Lighthouse resolves service names across clusters joined to an ACM hub, and it does not validate the IP addresses advertised in EndpointSlice objects. One compromised spoke cluster can publish EndpointSlices pointing at addresses it controls, and lighthouse DNS on the other clusters will then hand that address to callers of a legitimate service. The attacker sits transparently in the middle of cross-cluster traffic: model-serving calls, feature stores, checkpoint fetches and internal APIs that cross the cluster boundary can be read and altered without the caller seeing anything wrong. For operators running training and inference split across several clusters under one ACM hub, this means the blast radius of a single compromised cluster is every other cluster's cross-cluster service traffic.

Who can reach it

An attacker who has already compromised a spoke (managed) cluster joined to the ACM hub, with enough rights there to create EndpointSlice objects. Not reachable from an unprivileged pod on an unrelated cluster; the CVSS vector records PR:H.

What to do

Track Red Hat's errata for ACM 2.x - the record links the CVE and Bugzilla pages but names no fixed lighthouse build, so do not assume a version. Until an update ships, treat cross-cluster service export as trusted-cluster-only: limit which spokes are allowed to export services, restrict who can create or edit EndpointSlices on managed clusters, and prefer authenticated/mTLS transport for cross-cluster calls so a redirected endpoint cannot silently impersonate the real one. Applying the fix, when it lands, is a controller update on the hub and managed clusters rather than a node action.

References