La CISA a ajouté CVE-2025-62593, une vulnérabilité d'injection de code dans le framework d'IA Ray, à son catalogue des vulnérabilités exploitées connues le 17 août 2026. Le projet Ray indique que les versions antérieures à 2.52.0 sont concernées et que la version 2.52.0 corrige le problème. Son avis décrit une voie de DNS rebinding passant par le navigateur qui peut permettre l'exécution de code arbitraire contre un service Ray local utilisé par un développeur.
Il s'agit d'un signal actuel d'exploitation pour une divulgation plus ancienne, et non d'une preuve que chaque déploiement Ray est exposé. L'avis du fournisseur a été publié le 26 novembre 2025. Il décrit précisément un scénario impliquant Firefox ou Safari, un site malveillant et un service local de développement Ray en cours d'exécution. Les équipes doivent vérifier si ces conditions existent dans leur environnement avant de décrire l'impact.
Ce que dit la CISA sur la vulnérabilité du framework IA Ray
Le catalogue de la CISA nomme CVE-2025-62593 Ray Code Injection Vulnerability. L'entrée du 17 août indique que la faille peut permettre l'exécution de code à distance. Elle fixe au 20 août 2026 l'échéance de correction pour les agences fédérales américaines visées par la directive applicable de la CISA. Le champ relatif à l'utilisation connue par un rançongiciel porte la valeur unknown. Inconnu ne veut pas dire absent. Cela signifie que le catalogue n'attribue pas d'utilisation connue par un rançongiciel dans ce champ.
L'inscription au catalogue signifie que la CISA dispose de preuves d'une exploitation réelle. L'entrée publique ne précise ni victimes, ni volume d'exploitation, ni identité des attaquants, ni campagne. Ces détails ne doivent pas être déduits du statut dans le catalogue. Pour les organisations qui ne relèvent pas de la directive fédérale, la date d'échéance constitue un signal d'urgence, pas un délai juridique général.
Fonctionnement de la voie entre le navigateur et le service local
L'avis de sécurité du projet Ray explique la portée technique. Selon le projet, un attaquant peut utiliser le DNS rebinding depuis un site malveillant afin que des requêtes du navigateur atteignent un service Ray sur la machine d'un développeur. L'avis cite Firefox et Safari dans la voie d'exposition démontrée. Si l'exploitation réussit, l'attaquant peut soumettre des tâches à Ray et exécuter du code avec les autorisations disponibles pour ce service.
Ce point est important, car un service qui paraît local peut rester accessible par une requête relayée par le navigateur. Considérer l'interface de boucle locale comme une authentification suffisante laisse une faille lorsque le comportement du navigateur et du DNS permettent à une origine non fiable de s'adresser au service. La fiche NVD fournit l'enregistrement public de la CVE et renvoie les défenseurs vers l'avis du fournisseur et les références associées.
Les conditions comptent. L'avis n'établit pas que toutes les grappes de production, services Ray gérés ou navigateurs sont vulnérables de la même façon. L'exposition dépend de la version de Ray, de l'exécution et de l'accessibilité du service, du comportement du navigateur, de la configuration réseau et des privilèges du processus Ray. Selon l'avis, Chrome n'est pas concerné par la voie démontrée. Les équipes doivent néanmoins tester leurs versions de navigateur et leurs configurations exactes.
Pourquoi il s'agit d'un enjeu de gouvernance de l'infrastructure IA
Ray sert à distribuer des charges Python et d'intelligence artificielle. Un service Ray local compromis peut donc se trouver à proximité du code source, des artefacts de modèles, des jeux de données, des identifiants cloud, des notebooks et des accès de développement. Le problème immédiat est l'exécution de code. La conséquence pour la gouvernance est la perte de confiance dans l'identité de la personne ayant lancé une charge, les données consultées et l'intégrité des artefacts produits.
Une réponse fiable commence par un inventaire. Les équipes de sécurité doivent savoir où Ray est installé, quelles versions sont présentes, qui lance les services locaux, quelles voies de navigateur sont autorisées et à quels identifiants ou stockages ces processus peuvent accéder. Le guide Maetra sur la création d'un inventaire des agents d'IA propose un modèle utile pour consigner responsables, environnements, autorisations et dépendances, plutôt que de tenir uniquement une liste de paquets.
Réponse opérationnelle pour les équipes de sécurité et de plateforme
Appliquez les vérifications suivantes aux postes de développement, notebooks, environnements de compilation, systèmes de recherche et plateformes d'IA partagées :
- Rechercher les installations et services Ray actifs, puis consigner version, hôte, responsable, mode de lancement et usage de l'environnement.
- Mettre les installations concernées à niveau vers Ray 2.52.0 ou une version ultérieure, en suivant l'avis du fournisseur et les contrôles de changement habituels.
- Si la mise à niveau ne peut pas être achevée immédiatement, arrêter le service ou appliquer la mesure recommandée par le fournisseur, puis documenter le responsable et l'expiration de l'exception.
- Vérifier si les services Ray locaux utilisent l'emplacement réseau comme seule frontière de confiance. Ajouter des contrôles d'authentification, d'écoute, de pare-feu et d'origine du navigateur adaptés à l'environnement.
- Renouveler les identifiants et examiner les journaux pertinents lorsqu'un service exposé avait accès à des dépôts de code, jetons cloud, jeux de données ou artefacts de modèles.
- Tester la voie du navigateur et du DNS dans un environnement isolé. Ne pas supposer qu'une configuration est protégée uniquement parce que le service utilise localhost.
- Conserver pour chaque système concerné la preuve de la version corrigée, du redémarrage, du test d'exposition et de la décision de contrôle.
- Surveiller les tâches Ray, la création de processus, l'utilisation d'outils et les connexions sortantes afin de détecter un comportement contraire à l'usage approuvé.
La dernière étape reste importante après le correctif. Le guide Maetra sur la surveillance des comportements à risque des agents d'IA montre comment relier une action importante à un responsable, une décision de politique et un dossier contrôlable.
Analyse Maetra : les services d'IA locaux ont besoin de frontières de confiance explicites
La leçon générale est qu'une infrastructure d'IA locale ne présente pas automatiquement un faible risque. Les services de développement associent souvent une exécution puissante, des paramètres pratiques et un large accès à l'environnement de l'utilisateur. Le navigateur peut devenir un pont inattendu entre un site non fiable et cette capacité locale.
Les équipes doivent définir la frontière de confiance de chaque service d'IA en fonction de l'identité, de l'origine, de la voie réseau, des privilèges du processus, de l'accès aux données et des actions observables. Le niveau de correctif est un contrôle dans ce modèle. Il ne remplace ni la revue des identifiants, ni le moindre privilège, ni la journalisation, ni la preuve que la voie exposée est fermée.
Une prochaine étape concrète consiste à ajouter les services Ray à l'inventaire des systèmes d'IA, à relier chaque entrée à son dossier de vulnérabilité et de correction, puis à demander au responsable d'attester la version actuelle et les interfaces accessibles. Les équipes peuvent ensuite utiliser le workflow Secure de Maetra pour examiner les frontières des outils et des actions tout en maintenant la correction de l'infrastructure dans leur processus de sécurité établi.
Sources
- CISA : catalogue JSON des Known Exploited Vulnerabilities, CVE-2025-62593 ajoutée le 17 août 2026.
- Projet Ray : avis de sécurité GHSA-q279-jhrf-cc6v, publié le 26 novembre 2025.
- NIST National Vulnerability Database : CVE-2025-62593, fiche publique de la vulnérabilité.