La CISA donne 3 jours pour patcher Ray — j’ai relu l’avis 2 fois avant de comprendre le vecteur

Le catalogue des vulnérabilités activement exploitées de la CISA s’est enrichi ce 18 août 2026 d’une entrée qui mérite qu’on s’y arrête : CVE-2025-62593, une injection de code dans Ray, le moteur de calcul distribué d’Anyscale largement utilisé pour l’entraînement et le service de modèles. L’échéance de remédiation est fixée au 21 août, soit trois jours.

J’ai lu l’avis une première fois en diagonale et j’en ai tiré la conclusion habituelle : encore un service d’infrastructure exposé par erreur sur Internet, à mettre derrière un pare-feu. C’était faux, et c’est en le relisant que le vrai vecteur est apparu.

Cette faille ne s’attrape pas parce que votre cluster est exposé. Elle s’attrape parce qu’un de vos développeurs a ouvert un onglet. C’est une catégorie de risque que la plupart des politiques de sécurité d’entreprise ne couvrent pas, et c’est ce qui rend cette entrée au KEV intéressante bien au-delà des équipes qui utilisent Ray.

Les faits, tels que publiés

La vulnérabilité affecte toutes les versions de Ray antérieures à 2.52.0. Elle porte deux identifiants de faiblesse : CWE-94 pour l’injection de code et CWE-352 pour la falsification de requête intersites. La notation est de 9,4 sur 10 en CVSS 4.0 et de 8,8 en CVSS 3.1, avec un vecteur AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H.

Ce vecteur mérite une lecture attentive. PR:N signifie qu’aucun privilège n’est requis. UI:R indique qu’une interaction utilisateur est nécessaire — ce qui, ici, se réduit à visiter une page web. Et le triplet final marque un impact maximal en confidentialité, intégrité et disponibilité, c’est-à-dire une exécution de code à part entière.

Le calendrier est également instructif. La vulnérabilité a été publiée le 26 novembre 2025. Sa fiche a été mise à jour le 17 août 2026, et elle est entrée au catalogue KEV le lendemain. Autrement dit, le correctif était disponible depuis près de neuf mois quand l’exploitation constatée a justifié l’inscription.

Pourquoi « notre cluster n’est pas exposé » ne vous sauve pas

C’est la réaction que j’ai eue en première lecture, et c’est celle que j’entends depuis deux jours. Elle repose sur un modèle mental implicite : une vulnérabilité réseau se traite en fermant le port. Ici, ce raisonnement ne s’applique pas.

Le trafic malveillant ne vient pas d’Internet vers votre réseau. Il naît à l’intérieur de votre réseau, dans le navigateur d’une personne autorisée, et se dirige vers un service qui écoute en local sur sa propre machine. Aucun pare-feu périmétrique n’a de prise sur ce flux, parce qu’il ne traverse jamais le périmètre.

Le rebinding DNS est le mécanisme qui rend cela possible. Le principe est ancien et bien documenté : un nom de domaine contrôlé par l’attaquant répond d’abord par son adresse publique, le temps que la page se charge, puis répond par une adresse locale. Le navigateur considère alors qu’il parle toujours au même site et l’autorise à dialoguer avec le service local.

Ce qui transforme ce mécanisme en exécution de code, c’est le second problème signalé publiquement : l’absence d’authentification sur des points d’accès critiques tels que /api/jobs et /api/job_agent/jobs/. Soumettre une tâche à Ray, c’est par construction lui demander d’exécuter du code. Si l’appel n’est pas authentifié, l’exécution de code arbitraire n’est pas un détournement : c’est la fonctionnalité, appelée par la mauvaise personne.

Ce qu’il faut faire dans les 72 heures

L’échéance du 21 août ne s’impose juridiquement qu’aux agences fédérales américaines. Elle constitue néanmoins un repère raisonnable, parce qu’une entrée au catalogue KEV signale une exploitation constatée et non une hypothèse de laboratoire.

Premièrement, trouvez où Ray est installé. Le piège est de ne regarder que les serveurs. Cherchez aussi dans les environnements Python des postes de travail, dans les images de conteneurs de développement, et dans les dépendances transitives : Ray arrive fréquemment comme dépendance d’une bibliothèque d’apprentissage automatique, sans avoir jamais été installé volontairement.

Deuxièmement, mettez à jour vers 2.52.0. C’est la remédiation complète, et elle prime sur toute mesure de contournement.

Troisièmement, si une mise à jour immédiate est impossible sur un environnement critique, faites en sorte que le tableau de bord et l’interface de soumission de tâches ne soient accessibles qu’à travers un accès authentifié, et n’exécutez pas Ray en local sur une machine utilisée pour naviguer. Ce sont des mesures d’attente, pas des correctifs.

Quatrièmement, cherchez des traces. Les journaux de soumission de tâches sont l’endroit à regarder : une tâche soumise depuis une origine inattendue, à une heure incongrue, ou dont la commande ne ressemble à aucune de vos charges habituelles. Sur la mise en place de cette journalisation, notre méthodologie d’audit de périmètre NIS2 détaille les points de collecte à couvrir en priorité.

Le signal de fond : l’outillage d’IA hérite d’une dette de sécurité

Ray n’est pas un cas isolé, et c’est ce qui rend cette entrée au KEV significative. L’écosystème des outils de calcul et d’orchestration pour l’apprentissage automatique s’est construit sur une hypothèse implicite : ces composants tournent dans un environnement de recherche de confiance, entre gens qui se connaissent.

Cette hypothèse a produit des choix de conception cohérents à l’époque et intenables aujourd’hui — notamment l’absence d’authentification par défaut sur des points d’accès qui déclenchent l’exécution de code. Le même outillage se retrouve désormais dans des chaînes de production d’entreprise, avec des données réelles et une exposition réelle.

La conséquence pratique pour une organisation française est simple à formuler : les composants d’infrastructure d’IA doivent entrer dans votre inventaire au même titre que vos serveurs d’application, avec un responsable identifié et un suivi des vulnérabilités. Aujourd’hui, ils sont le plus souvent installés par les équipes de données, hors du champ de la gestion des correctifs.

Les équipes de Plug-Tech font le même constat côté déploiement de projets d’IA, et nos confrères de D-Open observent que ces dépendances arrivent souvent sans décision explicite, par transitivité.

Questions fréquentes

Quelles versions de Ray sont concernées par CVE-2025-62593 ?

Toutes les versions antérieures à 2.52.0. Le correctif est disponible dans la version 2.52.0, et la mise à jour est la seule remédiation complète. La vulnérabilité porte deux identifiants de faiblesse : CWE-94 pour l’injection de code et CWE-352 pour la falsification de requête intersites. Elle est notée 9,4 sur 10 en CVSS 4.0 et 8,8 en CVSS 3.1, avec un vecteur qui exige une interaction utilisateur — en l’occurrence, la simple visite d’une page web par la personne qui exécute Ray.

Pourquoi la CISA impose-t-elle une échéance au 21 août 2026 ?

Parce que l’inscription au catalogue des vulnérabilités activement exploitées déclenche mécaniquement un délai de remédiation court pour les agences fédérales américaines. L’ajout date du 18 août 2026 et l’échéance est fixée au 21 août, soit trois jours. Cette obligation ne s’applique pas juridiquement aux entreprises françaises, mais le catalogue reste le meilleur signal public disponible : une entrée au KEV signifie que l’exploitation est constatée sur le terrain, pas seulement théorique.

En quoi consiste concrètement l’attaque par rebinding DNS ici ?

Ray exposait des points d’accès sensibles sans authentification et se protégeait des requêtes venues d’un navigateur en vérifiant simplement que l’en-tête User-Agent commençait par « Mozilla ». Or la spécification fetch autorise la modification de cet en-tête, ce qui annule la garde. Un attaquant fait alors visiter une page malveillante — ou diffuse une publicité piégée — à un développeur qui exécute Ray en local ; le rebinding DNS permet à cette page de dialoguer avec le service qui tourne sur la machine de la victime, et d’y soumettre une tâche exécutant du code arbitraire.

Sommes-nous concernés si notre cluster Ray n’est pas exposé sur Internet ?

Très probablement oui, et c’est le contresens le plus fréquent sur cette faille. Le vecteur ne passe pas par une exposition réseau entrante : il part du navigateur de la personne qui exécute Ray. Un service écoutant uniquement en local, derrière un pare-feu et sans aucune ouverture depuis Internet, reste atteignable par une page web que cette personne consulte. La segmentation réseau périmétrique n’offre donc aucune protection ici ; seules la mise à jour vers 2.52.0 et l’authentification des points d’accès traitent le problème.

En résumé

CVE-2025-62593 est une vulnérabilité critique de Ray, corrigée en 2.52.0, entrée au catalogue KEV de la CISA le 18 août 2026 avec une échéance au 21 août. Son intérêt dépasse largement les organisations qui utilisent Ray.

Elle rappelle trois choses qui valent pour tout le monde. Un en-tête envoyé par le client n’est pas un contrôle de sécurité. Le poste du développeur est une cible de premier plan que la segmentation périmétrique ne protège pas. Et l’outillage d’IA installé par les équipes de données doit entrer dans le même inventaire de correctifs que le reste de votre parc — sans quoi vous découvrirez son existence le jour où un catalogue de vulnérabilités exploitées vous l’apprendra.