CVE-2026-64849 : le SSRF MLflow exploité dès sa divulgation

MLflow sous feu : quand une plateforme IA devient une porte d'entrée vers les credentials cloud

Le 18 août 2026, les chercheurs de la société watchTowr ont divulgué CVE-2026-64849, une vulnérabilité de type Server-Side Request Forgery (SSRF) affectant toutes les versions de MLflow antérieures à 3.15.0. Dans les heures qui ont suivi la publication, le réseau de honeypots mondial Attacker Eye de watchTowr a enregistré les premières tentatives d'exploitation en conditions réelles, ciblant des instances MLflow hébergées dans des environnements cloud. L'information a été reprise par The Hacker News, Decipher et CybersecurityNews, qui soulignent la rapidité sans précédent de la mise en exploitation de cette faille à peine connue.

MLflow est la plateforme open source de référence pour la gestion du cycle de vie des modèles de machine learning. Initialement développée par Databricks et publiée en 2018, elle est aujourd'hui utilisée par des dizaines de milliers d'organisations à travers le monde pour suivre les expériences d'entraînement, versionner les modèles, gérer les déploiements et organiser les pipelines MLOps. Sa présence dans les environnements cloud des entreprises — souvent avec des accès larges aux ressources AWS, Azure ou GCP nécessaires à l'entraînement des modèles — en fait une cible de choix pour un attaquant cherchant à élever ses privileges dans un environnement cloud.

La vulnérabilité réside dans l'endpoint de test webhook de MLflow, exposé par défaut sans authentification sur le chemin POST /api/2.0/mlflow/webhooks/{id}/test. Cet endpoint est conçu pour permettre aux utilisateurs de vérifier qu'un webhook configuré fonctionne correctement en déclenchant une requête de test vers l'URL de destination. Le problème fondamental est un défaut de type TOCTOU (Time-of-Check to Time-of-Use) dans la logique de validation de l'URL : le serveur MLflow valide bien l'URL de destination au moment de l'enregistrement du webhook, mais ne revalide pas cette URL au moment de l'exécution effective de la requête test.

Un attaquant peut exploiter ce décalage temporel de la manière suivante : il enregistre d'abord un webhook pointant vers un serveur qu'il contrôle, dont l'URL passe sans problème la validation initiale. Lorsque l'endpoint de test est déclenché, le serveur de l'attaquant répond à la requête de test MLflow par une redirection HTTP 301 ou 302 vers une ressource interne — typiquement le service de métadonnées cloud d'AWS (169.254.169.254), d'Azure (169.254.169.254) ou de GCP (metadata.google.internal). MLflow suit cette redirection sans revérifier la destination finale contre une liste d'adresses autorisées, permettant ainsi à l'attaquant d'accéder aux métadonnées de l'instance cloud, qui incluent en clair les credentials IAM temporaires de l'instance, les tokens d'accès, et d'autres secrets d'environnement.

En pratique, les credentials IAM ainsi récupérés permettent à un attaquant d'agir dans l'environnement cloud avec les permissions associées au rôle IAM de l'instance MLflow. Dans les environnements de production, ces rôles disposent fréquemment d'accès larges aux buckets S3, aux secrets Secrets Manager, aux clusters EMR ou aux registres de modèles — tout ce qui est nécessaire au fonctionnement d'un pipeline MLOps complet. Un attaquant ayant obtenu ces credentials peut exfiltrer des données d'entraînement, voler des modèles propriétaires, manipuler des artefacts de modèle, ou pivoter vers d'autres services cloud dans le même compte AWS.

Le caractère non authentifié de l'endpoint vulnérable aggrave considérablement le risque. Un attaquant n'a besoin d'aucune connaissance préalable de l'environnement cible ni d'aucun accès initial : il lui suffit d'atteindre réseau l'instance MLflow. Selon Rapid7, de nombreuses instances MLflow sont exposées publiquement sur Internet sans authentification — une configuration fréquente dans les environnements de développement et de recherche, qui ne devrait jamais être reproduite en production mais qui l'est régulièrement dans la réalité. La combinaison d'un accès public et d'un endpoint non authentifié fait de CVE-2026-64849 une vulnérabilité particulièrement dangereuse dans ces contextes.

IONIX et CVEfeed.io précisent que la faille peut également être exploitée via DNS rebinding, une technique permettant de contourner les protections basées sur la validation des adresses IP en manipulant la résolution DNS pour faire pointer temporairement un nom de domaine légitime vers une adresse interne. Cette variante d'exploitation est plus complexe à mettre en oeuvre mais contourne les mitigations qui se limitent à bloquer les redirections vers des adresses RFC 1918 sans inspecter la résolution DNS. Le correctif dans MLflow 3.15.0 adresse les deux vecteurs en imposant une validation stricte de la destination finale, qu'elle soit atteinte directement ou après redirection et quelle que soit la résolution DNS.

Les mitigations immédiates recommandées incluent : la mise à jour vers MLflow 3.15.0 dès que possible, la désactivation complète de la fonctionnalité webhook si elle n'est pas utilisée en production, l'ajout d'un reverse proxy avec authentification forte devant l'interface MLflow, et le verrouillage des règles de sortie réseau pour bloquer les connexions vers les plages d'adresses de métadonnées cloud (169.254.169.254, metadata.google.internal) depuis les instances hébergeant MLflow. MLflow publie également un patch de sécurité applicable aux versions 3.14.x pour les organisations ne pouvant pas immédiatement migrer.

La surface d'attaque des plateformes MLOps : un risque structurel sous-estimé

CVE-2026-64849 révèle une catégorie de risque encore insuffisamment prise en compte dans les stratégies de sécurité des organisations déployant des systèmes d'intelligence artificielle : la surface d'attaque des plateformes MLOps elles-mêmes. Les équipes de sécurité ont progressivement appris à évaluer les risques liés aux modèles IA — empoisonnement de données, attaques adversariales, extraction de modèles — mais la sécurité des infrastructures qui soutiennent le développement et le déploiement de ces modèles reste un angle mort fréquent. MLflow, comme d'autres plateformes de cette catégorie (Kubeflow, Weights and Biases, DVC, Feast), opère souvent avec des accès cloud très larges et constitue à ce titre une cible de choix pour des acteurs cherchant à compromettre des pipelines IA en production.

La rapidité d'exploitation observée — quelques heures entre la divulgation et les premières tentatives actives — illustre la professionnalisation croissante des acteurs cybercriminels dans leur surveillance des divulgations de CVE. Des infrastructures automatisées scrutent en permanence les publications de vulnérabilités sur les bases NVD/NIST, les dépôts GitHub, et les flux de chercheurs en sécurité, pour déclencher des scans de masse vers les instances exposées dès qu'une nouvelle faille est publiée. Cette réalité réduit dramatiquement la fenêtre de réaction disponible pour les équipes de sécurité entre la publication d'un patch et son déploiement effectif en production. Le délai moyen de patching en entreprise se mesure encore en semaines, là où les attaquants exploitent en heures.

L'impact potentiel de cette vulnérabilité dépasse le simple vol de credentials temporaires. Dans un environnement MLOps cloud, les modèles entraînés représentent des actifs intellectuels majeurs, parfois le fruit de mois ou d'années de travail et de millions d'euros de coûts de calcul. Les données d'entraînement, souvent propriétaires ou sensibles (données clients, données médicales, données financières), sont stockées dans des buckets accessibles aux rôles IAM associés à MLflow. La compromission d'une instance MLflow via CVE-2026-64849 peut donc aboutir à une exfiltration de données d'entraînement, au vol de modèles propriétaires, ou à l'injection de backdoors dans les artefacts de modèle stockés dans le registre — des scénarios qui s'apparentent à des attaques supply chain ciblant directement les systèmes IA d'une organisation.

Pour les RSSI et les équipes DevSecOps, cette vulnérabilité est également un signal d'alarme sur la nécessité d'appliquer aux plateformes MLOps les mêmes principes de sécurité que ceux appliqués aux autres composants critiques du système d'information. Cela implique : l'inventaire systématique de toutes les instances MLflow déployées dans l'organisation (y compris dans les environnements sandbox et de développement), l'application du principe de moindre privilege sur les rôles IAM associés, la mise en place d'une authentification forte sur les interfaces exposées, et l'intégration de MLflow dans les processus de gestion des vulnérabilités et de patching. La sécurité de l'IA commence par la sécurité de l'infrastructure qui la fait fonctionner.

Ce qu'il faut retenir

• CVE-2026-64849, SSRF sans authentification CVSS 9.3 dans MLflow, exploitée en quelques heures après divulgation pour voler des credentials cloud AWS via les services de métadonnées d'instance (169.254.169.254).
• Toutes les versions MLflow antérieures à 3.15.0 sont vulnérables ; les instances exposées publiquement sans authentification sont en danger immédiat d'exploitation.
• Patchez immédiatement vers MLflow 3.15.0, désactivez les webhooks si non utilisés, et restreignez les flux réseau sortants depuis vos instances MLflow vers les plages d'adresses de métadonnées cloud.