Trois fournisseurs sans lien, un calendrier identique

Ray est un framework open source natif Python utilisé pour exécuter des charges de travail d'entraînement et d'inférence IA et ML, avec plus de 43 500 étoiles sur GitHub et un usage répandu dans l'infrastructure IA d'entreprise. Une faille répertoriée sous CVE-2025-62593, avec un score CVSS de 9,4, permettait à un attaquant de combiner le DNS rebinding avec une simple visite via navigateur pour que la machine du développeur envoie elle-même des requêtes d'exécution de code à un cluster Ray local, car la vérification d'authentification des points de terminaison API de Ray se contentait de vérifier que l'en-tête User-Agent commençait par le mot Mozilla, une valeur que tout navigateur envoie par défaut.

GitLab, la plateforme de gestion de code source et de CI/CD utilisée dans tout le secteur, a divulgué CVE-2026-19478 le 17 août 2026 : une directive GraphQL avec un score CVSS de 9,4 qui permettait à un attaquant non authentifié de modifier ou supprimer des projets publics et des données utilisateur via le réseau sans aucune interaction de l'utilisateur. Apple a corrigé CVE-2026-65400 le 6 août 2026, un défaut de gestion d'état dans la validation des identifiants de macOS Screen Sharing, le service de bureau à distance intégré qui écoute sur le port réseau 5900. Trois organisations sans lien, trois produits sans lien, une fenêtre de six jours.

Du correctif à l'exploitation massive en quelques jours, pas en mois

Le botnet DDoS RondoDox a intégré un exploit fonctionnel pour la faille de Ray dès le 24 novembre 2025, deux jours entiers avant que la faille ne soit divulguée publiquement le 26 novembre 2025, car un proof-of-concept circulait déjà. Une seconde campagne, ShadowRay 2.0, recherche spécifiquement les clusters Ray non corrigés tournant sur des GPU NVIDIA et les transforme en botnets de minage de cryptomonnaie auto-répliquants, ce qui démontre que les attaquants ciblent désormais délibérément l'infrastructure d'entraînement IA pour sa puissance de calcul brute.

La faille Screen Sharing d'Apple a suivi le même schéma d'accélération. Le correctif est sorti le 6 août 2026, le Centre national de cybersécurité néerlandais (NCSC-NL) a confirmé une exploitation active contre des Mac exposés à internet, et dans chaque cas confirmé, l'attaquant obtenait un accès root et installait un mineur de cryptomonnaie Monero. La CISA a relevé le score de gravité de la faille de 7,1 à 9,8 le 14 août 2026, huit jours après le correctif, après avoir confirmé que l'exploit était devenu automatisable à grande échelle. La CISA a ajouté la faille de Ray à son catalogue Known Exploited Vulnerabilities le 17 août 2026, avec une échéance au 20 août 2026 pour les agences fédérales américaines.

Ce que cela signifie pour le rythme de correctifs

Rien de tout cela n'est exotique. Ray tourne sur des clusters d'entraînement IA, GitLab se situe dans la chaîne d'approvisionnement logicielle, et Screen Sharing est présent sur chaque Mac qu'une équipe informatique gère à distance : trois éléments d'infrastructure ordinaires que la plupart des organisations utilisent déjà. L'écart qui existait autrefois entre la publication d'un correctif par un fournisseur et son exploitation massive par des criminels se réduisait déjà depuis un moment, et le calendrier de Ray montre qu'il peut désormais devenir négatif : l'exploit a été armé avant même que le public ne sache que la faille existait.

Un cycle de correctifs mensuel ou trimestriel n'est plus une posture de sécurité défendable pour quoi que ce soit disposant d'une surface d'administration ou de développement exposée au réseau, et GitLab auto-hébergé, les clusters d'entraînement IA ainsi que les flottes de Mac gérées à distance entrent tous pleinement dans cette catégorie. La réponse pratique consiste à suivre le nombre de jours entre la publication du correctif et son déploiement complet comme indicateur suivi au niveau du conseil d'administration pour chacune de ces trois catégories, avec une attention particulière à l'infrastructure IA et ML auto-hébergée, car il s'agit d'une catégorie plus récente pour laquelle la plupart des équipes de sécurité n'ont pas encore mis en place de processus de correctif rapide.