OpenShift Multi-Cluster: 3 CVSS 9.9 CVEs in Submariner, Lighthouse and ACM

Three vulnerabilities rated CVSS 9.9 were published on August 19 and 20, 2026 against components of Red Hat's multi-cluster stack: Submariner, Lighthouse, and Advanced Cluster Management's search-v2-operator.

Taken separately, they're three authorization defects. Read together, they describe the same underlying problem: the hub-spoke trust model does not isolate spokes from one another. Two of the three explicitly assume a compromised spoke cluster and show it can then act on its peers — meaning the security of the entire fleet is that of its least-protected cluster.

For an organisation running a fleet of clusters at differing criticality levels — production, staging, a team's development cluster, an edge cluster — that directly undermines the segmentation they assume they have.

The Three CVEs

Shared vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

The PR:L (low privileges) and S:C (scope changed) tell the story: you need a foothold, but the impact crosses the cluster boundary.

CVE-2026-66785 — Submariner: hijacking peer clusters' traffic

Submariner provides layer-3 network connectivity between Kubernetes clusters: it establishes tunnels and advertises each cluster's address ranges so pods in one cluster can reach pods in another.

Red Hat's description:

This vulnerability allows a malicious cluster (spoke) to redirect network traffic from other connected clusters (peer clusters) by publishing a specially crafted network endpoint. The system fails to properly validate the network subnets provided by the malicious cluster, enabling it to declare arbitrary network ranges. Consequently, all network traffic intended for these arbitrary ranges from peer clusters will be rerouted through the attacker's tunnel.

The flaw is simple to state: a cluster advertises its own subnets, and nobody verifies they belong to it. At the scale of a Kubernetes federation, this is the equivalent of BGP prefix hijacking.

An attacker controlling one spoke declares 10.0.0.0/8, or the precise range of the service they want to intercept, and all peer-cluster traffic destined for that range enters their tunnel. They gain a man-in-the-middle position on inter-cluster flows that teams generally treat as internal and trusted — hence often unencrypted, without mTLS, because "it's the internal network."

CVE-2026-66788 — Lighthouse: injecting into peer clusters' kube-system

Lighthouse is Submariner's service discovery component: it propagates ServiceImport and EndpointSlice objects between clusters so multi-cluster DNS works.

Red Hat's description:

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-*.

The mechanism deserves emphasis because it illustrates a recurring design error in Kubernetes operators: the destination namespace is read from data the attacker controls. A label or annotation on an object is user input; using it as a write target without validation means letting the caller choose where the operator writes.

The concrete consequence: being able to create an EndpointSlice in kube-system allows redirecting system service resolution. An attacker who hijacks an infrastructure service in a peer cluster's system namespace intercepts control-plane communications — and does so via perfectly legitimate Kubernetes objects, created by an authorized operator, so without triggering any obvious alert.

CVE-2026-70496 — search-v2-operator: an operator with cluster-admin rights

Red Hat's description:

The operator's ClusterRole has permissions equivalent to a cluster administrator, allowing it to impersonate other entities, write Role-Based Access Control (RBAC) configurations, approve Certificate Signing Requests (CSRs), and manage ManifestWork. This grants excessive privileges beyond what is necessary for the operator's intended function, potentially leading to privilege escalation within the cluster.

This isn't a code bug: it's an over-broad ClusterRole, shipped as-is. Each of the four cited permissions is on its own a complete escalation path:

• impersonate — act as any user or service account, including system:masters
• RBAC write — grant yourself whatever rights you're missing
• CSR approval — issue a valid client certificate for the API server, i.e. a durable identity that survives token revocation
• ManifestWork management — in ACM, ManifestWork is how the hub pushes resources to spokes: controlling it means deploying whatever you like onto managed clusters

That last point is what connects this to the other two CVEs: an attacker who gains this operator's rights on the hub doesn't compromise a cluster, they compromise the fleet.

Affected Products and Versions

Red Hat does not expose a version list in the NVD data at the time of writing, and I won't guess one. The affected components:

To identify your versions and the applicable fixes, consult the corresponding Red Hat advisories (RHSA) on the customer portal. Check what's running:

# Installed operators and their versions
oc get csv -A | grep -Ei "submariner|advanced-cluster-management|search"

# ACM subscriptions
oc get subscription -n open-cluster-management

# The Submariner broker and registered clusters
oc get clusters.submariner.io -A
oc get gateways.submariner.io -A

Exploitation and Impact

The prerequisite, and why it's weaker than it looks

Both Submariner/Lighthouse CVEs assume a compromised spoke. That sounds like a high bar. It isn't, for three reasons:

1. Fleets are heterogeneous. A product team's development cluster, an edge cluster on a factory site, a staging cluster: they attach to the same hub as production, but they don't share its hardening, its monitoring, or its access constraints.
2. Admin rights on a non-critical cluster are handed out freely. Many organisations grant cluster-admin on the dev cluster to the whole team — reasonable in itself, but a problem once that cluster can act on its peers.
3. An edge cluster is physically reachable. On a remote site, in a factory, in a branch office, physical access isn't a theoretical assumption.

The mental model to correct: in a federation, attaching a cluster to the hub grants it the ability to act on the others, not merely access to shared services.

Consequences

• Interception of inter-cluster flows (CVE-2026-66785) — frequently unencrypted, because considered internal
• Hijacking system service resolution (CVE-2026-66788) on production clusters
• Fleet takeover (CVE-2026-70496) via ManifestWork and impersonation
• Persistence that's hard to revoke — a client certificate obtained via CSR approval survives token rotation
• Stealth — all three exploits work through legitimate Kubernetes objects created by authorized controllers, not malicious binaries an EDR would flag

Detection

Audit ClusterRoles holding dangerous permissions

This is the highest-value check, and it matters beyond these CVEs:

# ClusterRoles allowing impersonation
oc get clusterrole -o json | jq -r '
  .items[] | select(.rules[]? |
    (.verbs[]? == "impersonate")) | .metadata.name'

# ClusterRoles able to write RBAC
oc get clusterrole -o json | jq -r '
  .items[] | select(.rules[]? |
    (.apiGroups[]? == "rbac.authorization.k8s.io") and
    (.verbs[]? | test("create|update|patch|\\*"))) | .metadata.name'

# ClusterRoles able to approve CSRs
oc get clusterrole -o json | jq -r '
  .items[] | select(.rules[]? |
    (.resources[]? | test("certificatesigningrequests"))) | .metadata.name'

Any application operator appearing in all three lists deserves scrutiny, independent of CVE-2026-70496.

Subnets advertised by clusters

For CVE-2026-66785 the signal is direct: a cluster advertising a range that isn't its own.

oc get clusters.submariner.io -A -o custom-columns=\
'CLUSTER:.metadata.name,SERVICE_CIDR:.spec.service_cidr,CLUSTER_CIDR:.spec.cluster_cidr'

Compare each row against your documented addressing plan. A broad range (10.0.0.0/8) or an overlap with a CIDR belonging to another cluster is an unambiguous indicator.

Injected resources

For CVE-2026-66788, look for EndpointSlice and ServiceImport objects where they have no business being:

# ServiceImports outside expected application namespaces
oc get serviceimport -A

# EndpointSlices in system namespaces
oc get endpointslice -n kube-system
oc get endpointslice -A | grep -E "^openshift-"

A Lighthouse-managed EndpointSlice in kube-system or an openshift-* namespace has no legitimate reason to exist.

API server audit logs

# CSR approvals — a rare event, worth correlating every time
oc get events -A --field-selector reason=CSRApproved

Mitigation

1. Apply the Red Hat fixes

Check the corresponding RHSAs on the Red Hat portal for Submariner, Lighthouse and RHACM, and apply them through the operators.

2. Restrict the search-v2-operator ClusterRole

For CVE-2026-70496, pending the fix, you can strip the manifestly excessive permissions — but test in staging first: removing a permission the operator genuinely needs will break it. The four cited verbs (impersonate, RBAC write, CSR approval, ManifestWork) are the first candidates to examine.

3. Treat the spoke-to-spoke boundary as a security boundary

This is the structural measure, and the only one that will survive the next CVEs in this category:

• Don't attach clusters with sharply differing criticality to the same hub. A production fleet and a development fleet deserve two hubs.
• Encrypt inter-cluster traffic at the application layer (mTLS via a service mesh), so a hijacked tunnel doesn't yield the content.
• Restrict cluster-admin even on non-critical clusters, once they're federated.
• Monitor advertised CIDRs continuously, not only at install time.

4. If you conclude there was a compromise

1. Detach the suspect spoke from the broker before investigating
2. Audit advertised CIDRs and injected resources across every peer cluster
3. Revoke client certificates issued via CSR approval over the relevant period — this is the most stubborn persistence vector
4. Audit ManifestWork applied to spokes against your expected definitions
5. Rotate broker credentials and operator service account tokens

Why Continuous Monitoring of Kubernetes Operators Matters

Kubernetes operators are a category of software particularly poorly covered by vulnerability inventories: they're installed from a catalogue, update on their own channel, appear in no classic software inventory, and nobody in the organisation knows precisely which ClusterRoles they hold. Yet CVE-2026-70496 shows an operator can ship with cluster-admin-equivalent rights — not through a bug, but by design.

With cveo.tech, inventory your Kubernetes and OpenShift components — operators, CNI, service mesh, multi-cluster building blocks — and get automatic alerts whenever a critical CVE targets one of your exact versions. Because on a federated fleet, the question isn't "is this cluster up to date" but "can my weakest cluster reach the others".