Ray bloquait les navigateurs sur un User-Agent falsifiable et écope d’une RCE 9.4 au catalogue KEV

26 novembre 2025. La CVE-2025-62593 est publiée : une exécution de code à distance dans Ray, le moteur de calcul distribué d’Anyscale qui sert de socle à l’entraînement et à l’inférence de modèles d’IA. 17 août 2026. La CISA l’ajoute à son catalogue KEV (Known Exploited Vulnerabilities) avec une exploitation active confirmée. 20 août 2026. Échéance imposée aux agences fédérales américaines pour corriger.

Trois jours pour patcher. La raison de cette urgence tient en une phrase : la défense censée bloquer les navigateurs sur Ray reposait sur un en-tête User-Agent que Firefox et Safari permettent de falsifier. Ce n’était pas une défense.

Une défense qui n’en était pas une

Le tableau de bord de Ray expose des points de terminaison critiques, dont /api/jobs et /api/job_agent/jobs/, qui permettent de soumettre des tâches arbitraires au cluster. Pour empêcher une page web malveillante de les invoquer, l’équipe de Ray a fait un choix documenté depuis longtemps : n’implémenter aucune authentification, et se contenter d’un filtre d’heuristique.

Ce filtre est littéralement une chaîne de caractères. La fonction is_browser_request() considère qu’une requête provient d’un navigateur si — et seulement si — son en-tête User-Agent commence par la chaîne « Mozilla ». Le middleware browsers_no_post_put_middleware rejette alors les méthodes POST et PUT de ces « navigateurs » avec un 405.

L’hypothèse sous-jacente, écrite noir sur blanc dans le code, est que « fetch/xhr and friends cannot alter the user-agent ». Cette hypothèse est fausse. La spécification fetch autorise la modification de l’en-tête User-Agent, et Firefox comme Safari l’implémentent fidèlement. Chrome échappe à l’exploitation, ironie du sort, à cause d’un bug (l’issue Chromium 40450316) qui le maintient hors spécification.

Résultat : un attaquant n’a qu’à positionner User-Agent: Other dans un appel fetch pour passer le filtre et soumettre un job au cluster.

Le rebinding DNS transforme une visite en exécution de code

Contourner le filtre User-Agent ne suffit pas : encore faut-il que la requête atteigne le port local du développeur depuis une page distante. C’est le rôle du DNS rebinding.

Le principe est connu. Un domaine contrôlé par l’attaquant répond d’abord avec une adresse IP publique, puis — une fois le TTL expiré — avec une adresse privée comme 127.0.0.1. Le navigateur, qui croit toujours dialoguer avec le même hôte, envoie la requête vers la machine du visiteur. Un outil comme nccgroup/singularity automatise l’attaque de bout en bout.

La chaîne complète, décrite dans l’avis GitHub, est d’une banalité déconcertante. Le développeur lance Ray localement avec ray start --head --port=6379 et son tableau de bord écoute sur le port 8265. Il visite ensuite un site compromis — ou se fait servir une publicité malveillante (malvertising). Le DNS rebinding s’exécute, puis un appel POST /api/jobs/ avec l’en-tête User-Agent: Other soumet un entrypoint contenant une commande shell. Cette commande s’exécute avec les privilèges du développeur.

Le chercheur à l’origine du rapport, Jonathan Leitschuh (JLLeitschuh), précise avoir reproduit l’attaque plusieurs fois sur macOS, depuis différents réseaux résidentiels. Le payload de démonstration se contente d’ouvrir la calculatrice ; un payload réel exfiltrerait des clés, des modèles ou des identifiants cloud.

Aucune authentification, par conception

Le point le plus instructif de cet incident n’est pas le User-Agent : c’est la décision amont. L’avis GitHub l’énonce sans détour : l’équipe de Ray a fait le choix « de longue date » de ne pas implémenter d’authentification sur les points de terminaison critiques, « et ce choix a une fois de plus conduit à une vulnérabilité grave ».

Ce « une fois de plus » renvoie à un précédent documenté. Début 2024, des chercheurs avaient déjà montré que des clusters Ray exposés à Internet, sans authentification par défaut, pouvaient être détournés via l’API de soumission de jobs — la campagne dite ShadowRay avait vu des clusters de production compromis pour miner de la cryptomonnaie et exfiltrer des identifiants.

La CVE-2025-62593 est classée CWE-94 (injection de code) et CWE-352 (CSRF). Sa sévérité est élevée : CVSS 4.0 à 9.4 (critique, vecteur AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H) et CVSS 3.1 à 8.8. Le correctif, publié dans la version 2.52.0, durcit le contrôle en abandonnant le filtre User-Agent.

Le passage au KEV et le signal RondoDox

Le 17 août 2026, la CISA a fait passer la CVE-2025-62593 de l’état « PoC » à l’état « exploitation active » dans son score SSVC, avec un paramètre automatisable passé à « oui » et un impact technique « total ». Le même jour, elle l’ajoutait au KEV avec une échéance de remédiation fixée au 20 août 2026, dans le cadre de la directive BOD 26-04.

Le registre NVD porte une trace supplémentaire : l’entrée référence l’analyse du botnet RondoDox publiée par BitSight, ajoutée par la CISA-ADP le 17 août. Ce botnet, documenté depuis mai 2025, est connu pour scanner massivement les services exposés et exploiter un large catalogue de failles — 174 exploits recensés par BitSight. La présence de cette référence situe l’exploitation de Ray dans l’écosystème des botnets qui automatisent le compromis de services mal configurés.

Pour un RSSI, la leçon tient dans la mécanique de la faille : l’attaquant n’a besoin d’aucune interaction sophistiquée. Une visite sur un site compromis, une publicité servie par un réseau tiers, et le poste d’un développeur exécute du code.

Ce qu’il faut faire

La remédiation est simple et binaire. Mettez à jour Ray vers la version 2.52.0 ou supérieure : c’est la seule correction complète. Le commit 70e7c72780bdec075dba6cad1afe0832772bfe09 porte le correctif.

Trois mesures complémentaires réduisent l’exposition, quelle que soit la version :

• N’exposez jamais le tableau de bord (port 8265) sur Internet. Il doit rester lié à 127.0.0.1 ou derrière un VPN.
• Placez un reverse proxy authentifié devant le tableau de bord si vous devez y accéder à distance. L’absence d’authentification native de Ray fait de cette couche une obligation, pas une option.
• Bloquez le DNS rebinding à la source : un résolveur ou un pare-feu qui rejette les réponses pointant vers des plages privées (RFC 1918, lien-local) neutralise le vecteur pour toutes les applications, pas seulement Ray.

Dans un environnement Kubernetes, vérifiez aussi que le service du tableau de bord n’est pas publié via un Ingress ou un Service de type LoadBalancer sans contrôle d’accès.

Verdict

Si vous utilisez Ray en développement — entraînement local, notebooks, jobs distribués — mettez à jour vers 2.52.0 dès aujourd’hui. La fenêtre d’exploitation est réelle, automatisée, et l’échéance fédérale de trois jours reflète une exploitation active, pas une menace théorique.

Si vous opérez des clusters Ray en production, l’urgence est ailleurs : l’absence d’authentification native fait peser le risque sur chaque point de terminaison exposé. Un reverse proxy authentifié et une surface réseau minimale sont vos vraies défenses, bien plus que la version du paquet.

Le signal de fond : une « protection » fondée sur un en-tête que la spécification autorise à falsifier n’est pas une protection. Quand un contrôle de sécurité tient en une comparaison de chaîne de caractères, traitez-le comme un commentaire, pas comme un garde-fou.

Références

• NVD — CVE-2025-62593 Detail, consulté le 18 août 2026
• GitHub Security Advisory — GHSA-q279-jhrf-cc6v : Critical RCE Vulnerability against Ray Devs exploitable via Browser, publié le 26 novembre 2025
• CISA — Known Exploited Vulnerabilities Catalog, ajout du 17 août 2026
• The Hacker News — CISA Flags Actively Exploited Ray Flaw That Can Trigger Browser-Based RCE, 18 août 2026
• BitSight — RondoDox Botnet: From Zero to 174 Exploited Vulnerabilities, 11 mars 2026
• nccgroup/singularity — DNS rebinding attack framework