OpenShift multi-cluster : 3 CVE 9.9 sur Submariner, Lighthouse et ACM

Trois vulnérabilités classées CVSS 9.9 ont été publiées les 19 et 20 août 2026 sur des composants de la pile multi-cluster de Red Hat : Submariner, Lighthouse et l'opérateur search-v2 d'Advanced Cluster Management.

Prises séparément, ce sont trois défauts d'autorisation. Lues ensemble, elles décrivent le même problème de fond : le modèle de confiance hub-spoke n'isole pas les spokes entre eux. Deux des trois partent explicitement de l'hypothèse d'un cluster spoke compromis et montrent qu'il peut alors agir sur ses pairs — ce qui signifie que la sécurité de l'ensemble de la fédération est celle de son cluster le moins bien protégé.

Pour une organisation qui gère une flotte de clusters avec des niveaux de criticité différents — production, préproduction, cluster de développement d'une équipe, cluster en périphérie — c'est une remise en cause directe de la segmentation supposée.

Les trois CVE

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

Le PR:L (privilèges faibles) et le S:C (scope changed) racontent l'histoire : il faut un pied dans le système, mais l'impact traverse la frontière du cluster.

CVE-2026-66785 — Submariner : détourner le trafic des clusters pairs

Submariner assure la connectivité réseau de niveau 3 entre clusters Kubernetes : il établit des tunnels et annonce les plages d'adresses de chaque cluster pour que les pods d'un cluster puissent joindre ceux d'un autre.

Description Red Hat :

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.

Le défaut est simple à énoncer : un cluster annonce ses propres sous-réseaux, et personne ne vérifie qu'ils lui appartiennent. C'est l'équivalent, à l'échelle d'une fédération Kubernetes, du détournement de préfixe BGP.

Un attaquant qui contrôle un spoke déclare 10.0.0.0/8, ou la plage précise du service qu'il veut intercepter, et tout le trafic des clusters pairs à destination de cette plage entre dans son tunnel. Il obtient une position d'homme du milieu sur des flux inter-clusters que les équipes considèrent généralement comme internes et de confiance — donc souvent en clair, sans mTLS, parce que « c'est du réseau interne ».

CVE-2026-66788 — Lighthouse : injecter dans kube-system des clusters pairs

Lighthouse est le composant de découverte de services de Submariner : il propage les ServiceImport et EndpointSlice entre clusters pour que le DNS multi-cluster fonctionne.

Description Red Hat :

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

Le mécanisme mérite d'être souligné parce qu'il illustre une erreur de conception fréquente dans les opérateurs Kubernetes : le namespace de destination est lu depuis une donnée que l'attaquant contrôle. Un label ou une annotation sur un objet est une entrée utilisateur ; l'utiliser comme cible d'écriture sans validation revient à laisser l'appelant choisir où l'opérateur écrit.

La conséquence concrète : pouvoir créer un EndpointSlice dans kube-system permet de rediriger la résolution de services système. Un attaquant qui détourne un service d'infrastructure dans le namespace système d'un cluster pair intercepte des communications de plan de contrôle — et le fait via des objets Kubernetes parfaitement légitimes, créés par un opérateur autorisé, donc sans déclencher d'alerte évidente.

CVE-2026-70496 — search-v2-operator : un opérateur avec les droits de cluster-admin

Description Red Hat :

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.

Ce n'est pas un bug de code : c'est un ClusterRole trop large, livré tel quel. Chacune des quatre permissions citées est à elle seule une voie d'escalade complète :

• impersonate — agir au nom de n'importe quel utilisateur ou service account, y compris system:masters
• écriture RBAC — s'attribuer soi-même les droits qui manqueraient
• approbation de CSR — émettre un certificat client valide pour l'API server, donc une identité durable qui survit à la révocation d'un token
• gestion de ManifestWork — dans ACM, ManifestWork est le mécanisme par lequel le hub pousse des ressources vers les spokes : le contrôler, c'est déployer ce qu'on veut sur les clusters gérés

Le dernier point est celui qui fait le lien avec les deux autres CVE : un attaquant qui obtient les droits de cet opérateur sur le hub ne compromet pas un cluster, il compromet la flotte.

Produits et versions affectés

Red Hat n'expose pas de liste de versions dans les données NVD au moment de la rédaction, et je ne vais pas en deviner. Les composants concernés :

Pour identifier tes versions et les correctifs applicables, il faut passer par les advisories Red Hat (RHSA) correspondants sur le portail client. Vérifier ce qui tourne :

# Opérateurs installés et leurs versions
oc get csv -A | grep -Ei "submariner|advanced-cluster-management|search"

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

# Le broker Submariner et les clusters enregistrés
oc get clusters.submariner.io -A
oc get gateways.submariner.io -A

Exploitation et impact

Le prérequis, et pourquoi il est plus faible qu'il n'y paraît

Les deux CVE Submariner/Lighthouse supposent un spoke compromis. Ça ressemble à une barrière haute. Ce n'en est pas une, pour trois raisons :

1. Les flottes sont hétérogènes. Un cluster de développement d'une équipe produit, un cluster en périphérie sur un site industriel, un cluster de préproduction : ils sont rattachés au même hub que la production, mais ils n'ont ni le même durcissement, ni la même surveillance, ni les mêmes contraintes d'accès.
2. Les droits d'admin sur un cluster non critique sont largement distribués. Beaucoup d'organisations donnent cluster-admin sur le cluster de dev à toute l'équipe, ce qui est raisonnable en soi — mais devient un problème si ce cluster peut agir sur ses pairs.
3. Un cluster en périphérie est physiquement accessible. Sur un site distant, en usine, en agence, l'hypothèse d'un accès physique n'est pas théorique.

Le modèle mental à corriger : dans une fédération, rattacher un cluster au hub, c'est lui accorder une capacité d'action sur les autres, pas seulement lui donner accès à des services partagés.

Conséquences

• Interception de flux inter-clusters (CVE-2026-66785) — souvent non chiffrés, parce que considérés comme internes
• Détournement de la résolution de services système (CVE-2026-66788) sur des clusters de production
• Prise de contrôle de la flotte (CVE-2026-70496) via ManifestWork et l'usurpation d'identité
• Persistance difficile à révoquer — un certificat client obtenu par approbation de CSR survit à la rotation des tokens
• Furtivité — les trois exploitations passent par des objets Kubernetes légitimes créés par des contrôleurs autorisés, pas par des binaires malveillants qu'un EDR détecterait

Détection

Audit des ClusterRoles à privilèges dangereux

C'est le contrôle le plus rentable, et il vaut au-delà de ces CVE :

# ClusterRoles autorisant l'usurpation d'identité
oc get clusterrole -o json | jq -r '
  .items[] | select(.rules[]? |
    (.verbs[]? == "impersonate")) | .metadata.name'

# ClusterRoles pouvant écrire du 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 pouvant approuver des CSR
oc get clusterrole -o json | jq -r '
  .items[] | select(.rules[]? |
    (.resources[]? | test("certificatesigningrequests"))) | .metadata.name'

Tout opérateur applicatif qui apparaît dans ces trois listes est à questionner, indépendamment de CVE-2026-70496.

Sous-réseaux annoncés par les clusters

Pour CVE-2026-66785, le signal est direct : un cluster qui annonce une plage qui n'est pas la sienne.

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

Compare chaque ligne à ton plan d'adressage documenté. Une plage large (10.0.0.0/8) ou le chevauchement d'un CIDR appartenant à un autre cluster est un indicateur non ambigu.

Ressources injectées

Pour CVE-2026-66788, cherche des EndpointSlice et ServiceImport là où ils n'ont rien à faire :

# ServiceImports hors des namespaces applicatifs attendus
oc get serviceimport -A

# EndpointSlices dans les namespaces système
oc get endpointslice -n kube-system
oc get endpointslice -A | grep -E "^openshift-"

Un EndpointSlice géré par Lighthouse dans kube-system ou un namespace openshift-* n'a aucune raison légitime d'exister.

Journaux d'audit de l'API server

# Approbations de CSR — événement rare, à corréler systématiquement
oc get events -A --field-selector reason=CSRApproved

Mitigation

1. Appliquer les correctifs Red Hat

Consulte les RHSA correspondants sur le portail Red Hat pour Submariner, Lighthouse et RHACM, et applique-les via les opérateurs.

2. Restreindre le ClusterRole de search-v2-operator

Pour CVE-2026-70496, en attendant le correctif, tu peux retirer les permissions manifestement excessives — mais teste en préproduction : retirer une permission dont l'opérateur a réellement besoin le mettra en échec. Les quatre verbes cités (impersonate, écriture RBAC, approbation de CSR, ManifestWork) sont les candidats à examiner en premier.

3. Traiter la frontière entre spokes comme une frontière de sécurité

C'est la mesure structurelle, et la seule qui survivra aux prochaines CVE de cette catégorie :

• Ne pas rattacher au même hub des clusters dont les niveaux de criticité diffèrent fortement. Une flotte de production et une flotte de développement méritent deux hubs.
• Chiffrer les communications inter-clusters au niveau applicatif (mTLS via un service mesh), pour qu'un détournement de tunnel ne donne pas accès au contenu.
• Restreindre cluster-admin même sur les clusters non critiques, dès lors qu'ils sont fédérés.
• Surveiller les CIDR annoncés en continu, pas seulement à l'installation.

4. Si tu conclus à une compromission

1. Détacher le spoke suspect du broker avant toute investigation
2. Auditer les CIDR annoncés et les ressources injectées sur tous les clusters pairs
3. Révoquer les certificats clients émis par approbation de CSR sur la période concernée — c'est le vecteur de persistance le plus tenace
4. Auditer les ManifestWork appliqués aux spokes contre tes définitions attendues
5. Faire tourner les credentials du broker et les tokens de service accounts des opérateurs

Pourquoi surveiller en continu vos opérateurs Kubernetes

Les opérateurs Kubernetes sont une catégorie de logiciel particulièrement mal couverte par les inventaires de vulnérabilités : ils sont installés par un catalogue, se mettent à jour selon leur propre canal, ne figurent dans aucun inventaire logiciel classique, et personne dans l'organisation ne sait précisément quels ClusterRoles ils détiennent. Or CVE-2026-70496 montre qu'un opérateur peut être livré avec des droits équivalents à cluster-admin — non pas à cause d'un bug, mais par conception.

Avec cveo.tech, inventorie tes composants Kubernetes et OpenShift — opérateurs, CNI, service mesh, briques multi-cluster — et reçois une alerte automatique dès qu'une CVE critique cible une de tes versions exactes. Parce que sur une flotte fédérée, la question n'est pas « ce cluster est-il à jour » mais « le plus faible de mes clusters peut-il atteindre les autres ».