CVE-2026-66785 is a high severity (CVSS 8.7) flaw in Submariner, shipped in Red Hat Advanced Cluster Management for Kubernetes. A malicious spoke cluster can publish a crafted network endpoint and redirect traffic from peer clusters. Red Hat fixed it in RHSA-2026:63016, which brings Submariner v0.24 for ACM 2.17.
What's affected
Red Hat Advanced Cluster Management for Kubernetes, through its Submariner component. Red Hat describes it as a malicious spoke cluster publishing a specially crafted network endpoint. The system fails to properly validate the subnets in the endpoint, so the spoke can declare arbitrary network ranges. Traffic from peer clusters meant for those ranges is then rerouted through the attacker's tunnel.
Red Hat rates the issue Important. Its CVE page shows a CVSS v3 base score of 8.7 with the vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N, which matches the record's 8.7. The weakness is CWE-345, insufficient verification of data authenticity. The record has no KEV listing for it, and Red Hat's page does not mention exploitation.
The fix ships in Red Hat's errata RHSA-2026:63016, issued on 3 September 2026. Its synopsis is "Important: Submariner v0.24 security fixes and container updates", and it applies to Red Hat Advanced Cluster Management for Kubernetes 2.17. The errata page lists 13 CVEs fixed in the same release, including this one and its sibling entry.
Red Hat's CVE page says mitigation for this issue is not available, or the available options do not meet its criteria for ease of use and wide applicability. That makes the update the main control.
How to check if you're exposed
Find the clusters where Submariner or Red Hat Advanced Cluster Management multi-cluster networking is installed, and read the installed version. These commands help on a hub or spoke cluster:
kubectl get csv -A | grep -i submariner
subctl show versions
Compare what you find with Submariner v0.24 from the errata. The CVE page lists the affected product as Red Hat Advanced Cluster Management for Kubernetes. I did not find a per version range on the pages I fetched, so use the errata and your Red Hat subscription portal to confirm which builds you run.
The precondition is a compromised or malicious spoke cluster that is connected to your other clusters. That is the scenario to model: ask which of your connected clusters are less trusted than the others.
What to do now
- List every cluster that joins a Submariner or ACM multi-cluster setup.
- Apply RHSA-2026:63016, which brings Submariner v0.24 for ACM 2.17.
- Identify the spoke clusters with the weakest controls and consider whether they should be joined to the same fabric as your most sensitive ones.
- Monitor for unexpected network ranges or endpoints published by spoke clusters.
- Rotate credentials for any spoke cluster you suspect is compromised.
Why it matters
Submariner connects pods and services across Kubernetes clusters. Each cluster advertises its network ranges to the others. If a receiving cluster accepts any range the sender claims, then a sender can claim ranges that belong to someone else, and the traffic follows.
Red Hat says the result could be unauthorized information disclosure or network disruption. The Bugzilla title mentions missing validation of remote Endpoint subnets and the cluster identifier. The practical lesson is that peer clusters must not trust each other's announcements blindly.
The CVSS vector uses a changed scope and high privileges required. The privilege is control of one spoke, and the changed scope shows that the harm reaches other clusters. A flaw like this erodes the isolation between clusters, which is the reason people split workloads across them.
Quick check
Does the attacker need access to my cluster?
The attacker needs control of a spoke cluster that is already connected to yours. That is the privilege the CVSS vector calls high.
Is there a workaround?
Red Hat says mitigation is not available or does not meet its criteria. Apply the errata.
Is this the same as CVE-2026-66787?
No. That entry covers the lighthouse DNS component and is fixed in the same errata.
Sources
Last reviewed: 18 October 2026.
