MLflow sous attaque : une SSRF critique expose des identifiants cloud et des services internes

La CISA ajoute CVE-2026-64849 à son catalogue KEV

La CISA a signalé l’exploitation active de CVE-2026-64849, une vulnérabilité critique affectant MLflow, une plateforme open source utilisée pour développer, évaluer et superviser des modèles de machine learning, des applications d’intelligence artificielle et des Large Language Models.

La faille est une Server-Side Request Forgery (SSRF) classée CWE-918. Un attaquant distant non authentifié peut contraindre le serveur MLflow à envoyer des requêtes vers des ressources internes qui ne sont pas directement accessibles depuis Internet.

CVE-2026-64849 a été ajoutée au catalogue CISA Known Exploited Vulnerabilities (KEV) le 19 août 2026. Pour les agences fédérales civiles américaines, la date limite de remédiation est fixée au 2 septembre 2026.

La vulnérabilité affiche un score CVSS 3.1 de 9.3, avec le vecteur suivant :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N

Ce score reflète l’absence d’authentification requise, la possibilité d’une exploitation à distance et l’impact élevé sur la confidentialité. La CISA décrit également l’exploitation comme active, automatisable et dotée d’un impact technique total.

Selon les informations disponibles, les attaquants ont commencé à rechercher des systèmes MLflow vulnérables quelques heures après l’attribution du CVE. La CISA n’a fourni aucun détail supplémentaire sur les attaques observées.

Quelles installations MLflow sont exposées

Le risque concerne principalement les tracking servers lancés avec la commande :

mlflow server

et configurés sans authentification, avec la base SQLite par défaut :

sqlite:///mlflow.db

Cette configuration est importante, car les webhooks du model registry nécessitent un SQL store. Le serveur par défaut remplit donc les conditions permettant d’exposer les API concernées.

Une installation est particulièrement exposée lorsque le tracking server :

• est accessible depuis Internet ;
• ne requiert aucune authentification ;
• peut accéder à des réseaux internes ou à des services cloud ;
• peut communiquer avec les endpoints de métadonnées des instances ;
• utilise les fonctionnalités de webhook du model registry.

MLflow enregistre plus de 30 millions de téléchargements par mois et est utilisé par des milliers d’organisations. La vulnérabilité peut donc affecter des environnements de développement, des plateformes MLOps et des infrastructures cloud hébergeant des modèles ou des pipelines d’IA.

Les informations relatives aux versions ne sont pas parfaitement cohérentes entre les différents avis de sécurité. La NVD considère comme vulnérables toutes les versions antérieures à la 3.15.0. Le GitHub Security Advisory indique pour sa part que les versions concernées vont jusqu’à la 3.13.0 incluse, tout en mentionnant une correction dans la version 3.15.0 et le correctif #24258.

L’exploit a été confirmé sur MLflow 3.13.0 avec la base SQLite par défaut. Par mesure de précaution, les installations antérieures à la 3.15.0 doivent être considérées comme vulnérables.

Comment fonctionne le contournement de la SSRF

Le principal vecteur implique l’endpoint non authentifié :

POST /api/2.0/mlflow/webhooks/{id}/test

Cet endpoint sert à tester un webhook et renvoie à l’appelant l’état de la réponse reçue du service distant, ainsi que son contenu.

MLflow effectue un contrôle initial de l’URL du webhook. Il vérifie le schéma, résout le nom d’hôte et refuse les adresses non publiques, notamment les adresses privées, loopback, link-local et celles destinées aux services de métadonnées. En temps normal, seul le schéma https est autorisé.

Cependant, ce contrôle ne lie pas l’adresse IP vérifiée à la connexion ultérieure. Le composant de distribution :

• suit automatiquement les redirections HTTP ;
• ne désactive pas allow_redirects ;
• ne revalide pas l’URL contenue dans l’en-tête Location ;
• peut effectuer une nouvelle résolution DNS au moment de la connexion.

L’attaquant peut ainsi enregistrer un webhook vers un hôte HTTPS public apparemment légitime. Après avoir passé la validation, son serveur répond par une redirection 302 vers une ressource interne, par exemple :

http://169.254.169.254/latest/meta-data/iam/security-credentials/

Le serveur MLflow suit la redirection et exécute la requête depuis son propre environnement réseau. L’endpoint /test renvoie ensuite à l’attaquant le code HTTP et le corps de la réponse upstream.

Le second contournement exploite le DNS rebinding. La résolution DNS effectuée lors du contrôle initial peut renvoyer une adresse publique, tandis que celle réalisée par la bibliothèque HTTP au moment de la connexion peut pointer vers une adresse interne. Comme l’IP approuvée n’est pas figée lors de la validation, la requête peut atteindre une destination différente.

La vulnérabilité permet de contacter :

• les endpoints AWS IMDS et d’autres services de métadonnées cloud ;
• des services d’administration internes ;
• des adresses loopback ;
• des ports et hôtes appartenant à des réseaux privés ;
• des systèmes non exposés au-delà du périmètre réseau.

L’accès aux métadonnées cloud peut exposer des identifiants temporaires AWS IAM, des jetons et d’autres secrets. La SSRF peut également être utilisée pour effectuer du balayage de ports et découvrir des hôtes internes.

L’avis de sécurité distingue une SSRF « blind », liée au parcours normal de distribution des événements, d’une SSRF permettant la lecture de la réponse, accessible via l’endpoint /test.

Le PoC démontre la récupération de données internes

La démonstration publiée suit trois étapes.

Tout d’abord, une tentative est effectuée pour enregistrer un webhook vers une adresse locale, comme 127.0.0.1. Le contrôle renvoie une erreur HTTP 400, car le schéma ou l’adresse ne sont pas autorisés.

Ensuite, un webhook est enregistré vers un hôte HTTPS public contrôlé par l’attaquant. L’URL passe la validation et est acceptée.

Enfin, le serveur de l’attaquant répond par une redirection vers un service interne. L’attaquant appelle alors l’endpoint /test, qui peut renvoyer une structure similaire :

{
  "result": {
    "success": true,
    "response_status": 200,
    "response_body": "<contenu du service interne>"
  }
}

Lors d’un test local, le chercheur a inséré manuellement dans le service interne des valeurs telles que :

INTERNAL_SECRET=mlflow_ssrf_proof_7f3a91
role=admin

Il ne s’agissait pas de véritables identifiants cloud. Le test démontre toutefois que le corps de la réponse interne peut être transmis à l’attaquant.

L’attaque ne nécessite aucune authentification et est exécutée par le serveur MLflow, et non par le navigateur ou l’ordinateur de la victime. Les valeurs des événements doivent en outre utiliser des noms proto en majuscules, tels que REGISTERED_MODEL et CREATED.

Correctif, mesures d’atténuation et réponse à incident

Le correctif est disponible dans MLflow 3.15.0 et est associé à la pull request #24258 ainsi qu’au commit :

ba949522477cbd5915aa55d29b0cfad7d5ddf939

Le projet a introduit SSRFProtectedHTTPAdapter, qui vérifie l’adresse IP du socket distant immédiatement après la connexion et avant tout échange TLS ou HTTP. Ce contrôle s’applique également aux redirections, empêchant de réutiliser le contournement avec des réponses 302, 307 et 308.

Cette mesure corrige également le problème de DNS rebinding : l’IP effectivement contactée est vérifiée, au lieu de se fier uniquement à la résolution initiale.

Les administrateurs doivent :

1. mettre à jour MLflow vers la version 3.15.0 ou ultérieure ;
2. donner la priorité aux tracking servers exposés sur Internet et dépourvus d’authentification ;
3. activer une authentification effective et vérifier les autorisations des webhooks ;
4. limiter les connexions sortantes du processus MLflow ;
5. bloquer l’accès à 169.254.169.254, aux réseaux privés, aux adresses loopback et aux services d’administration non nécessaires ;
6. contrôler les proxys, les pare-feu et le filtrage des flux sortants afin d’empêcher les requêtes vers des destinations internes.

Les journaux doivent être analysés à la recherche de requêtes vers :

/api/2.0/mlflow/webhooks
/api/2.0/mlflow/webhooks/{id}/test

Sont également suspects l’enregistrement de webhooks vers des hôtes externes inattendus, les redirections vers des adresses privées et les accès à 169.254.169.254.

Si l’instance a pu être exploitée, il est nécessaire de vérifier l’éventuelle exposition d’identifiants cloud, de jetons et de secrets. Les identifiants AWS IAM potentiellement compromis doivent être révoqués ou renouvelés, en accompagnant cette intervention d’une analyse des utilisations ultérieures.

La vulnérabilité a été signalée de manière privée le 12 juin 2026 par @freeman-bb. Une analyse indépendante réalisée par @AUTHENSOR a été rendue publique le 26 juin 2026 dans l’issue #24179.

CVE-2026-64849 ne doit pas être confondue avec CVE-2025-14279, qui concerne une vulnérabilité CSRF avec DNS rebinding et relève de la catégorie CWE-352, et non d’une SSRF server-side de ce type.