MLflow rejoint le KEV de la CISA après une SSRF qui lit les métadonnées du cloud
Le 19 août 2026, la CISA a inscrit CVE-2026-64849, une SSRF non authentifiée dans MLflow, à son catalogue des vulnérabilités activement exploitées. Tout serveur de tracking MLflow exposé doit passer en 3.15.0 et couper les webhooks inutilisés avant l’échéance du 2 septembre 2026.
19 août 2026. CVSS 9.3. Exploitation active. La CISA a inscrit CVE-2026-64849 au catalogue KEV des vulnérabilités exploitées dans la nature, avec une échéance de correction fixée au 2 septembre 2026. La cible n’est ni un pare-feu ni un VPN, mais MLflow, la plateforme open source qui sert de registre de modèles et de serveur de tracking aux équipes qui mettent des LLM et des agents en production. La faille est une SSRF non authentifiée : une seule requête suffit pour lire les métadonnées cloud de l’infrastructure qui héberge le serveur.
Une SSRF dans l’endpoint de test des webhooks
MLflow expose un endpoint de webhooks qui déclenche des notifications quand l’état d’un modèle ou d’un registre change — pratique pour brancher un pipeline CI/CD ou un canal d’alerte. Le problème se niche dans la route POST /api/2.0/mlflow/webhooks/{id}/test, qui permet de tester un webhook en envoyant une requête vers l’URL configurée. Cette route est accessible sans authentification.
La validation d’URL existe, mais elle est incomplète. La fonction _validate_webhook_url(), dans mlflow/utils/validation.py, ne contrôle que l’URL d’origine fournie par l’appelant. Or le code d’envoi, dans mlflow/webhooks/delivery.py, suit les redirections et re-résout le nom d’hôte sans ré-épingler l’adresse validée. Résultat : un attaquant soumet une URL publique en apparence bénigne, qui redirige vers une adresse interne — 127.0.0.1, un service d’administration, ou l’endpoint de métadonnées cloud 169.254.169.254.
Ce n’est pas une SSRF « aveugle ». L’endpoint renvoie au client le corps de la réponse (response_body) et le code de statut (response_status). L’attaquant lit donc ce que la cible lit. C’est ce détail qui pousse le score à 9.3 : confidentialité totale (C:H), complexité faible, aucun privilège, aucune interaction.
Pourquoi c’est grave : la route vers vos credentials
La conséquence la plus coûteuse tient en une adresse IP : 169.254.169.254. C’est l’Instance Metadata Service (IMDS) d’AWS — et ses équivalents chez GCP, Azure et les autres clouds. Interrogé depuis l’intérieur d’une machine, l’IMDS renvoie les identifiants temporaires du rôle IAM attaché à l’instance, sans authentification si IMDSv1 est encore actif.
Une SSRF qui atteint l’IMDS transforme donc une simple lecture de webhook en vol de credentials cloud. Si le serveur MLflow tourne sur une instance dotée d’un rôle large — typiquement le rôle qui lit S3, écrit dans le registre et orchestre les jobs d’entraînement — l’attaquant récupère de quoi pivoter vers le reste du compte. Le scope changed du vecteur CVSS (S:C) dit exactement cela : la compromission sort de la machine pour toucher une autre couche.
Ce schéma n’est pas nouveau — il a fait les beaux jours des attaques contre Capital One et tant d’autres — mais il trouve ici un nouveau terrain : l’infrastructure MLOps, qui concentre modèles, données et secrets, est historiquement moins durcie que les serveurs web qu’elle alimente.
Le signal du KEV : ce n’est plus théorique
L’inscription au KEV n’est pas une alerte de routine. La CISA n’y ajoute que des failles réellement exploitées par des attaquants, avec une preuve d’exploitation et un impact significatif. CVE-2026-64849 y figure désormais, ce qui signifie que des acteurs ont déjà automatisé la chaîne : scan d’Internet pour trouver des serveurs MLflow exposés, puis requête vers l’endpoint de test de webhook pour lire les métadonnées.
L’échéance 2 septembre 2026 correspond à la date butoir fixée par la directive opérationnelle contraignante (BOD 22-01) de la CISA pour les agences fédérales américaines. Pour le privé, c’est une échéance indicative — mais la logique reste : une faille activement exploitée, lisible (pas aveugle) et non authentifiée ne se traite pas à la semaine.
MLflow, colonne vertébrale silencieuse du MLOps
Pour comprendre l’exposition, il faut situer MLflow. C’est l’un des outils open source les plus déployés du cycle de vie MLOps : il traque les expériences, versionne les modèles et sert de registre central. Les équipes qui déploient des agents et des LLM le branchent à LangChain, Dagster, Kubeflow ou leurs pipelines maison.
Le problème est structurel. Un serveur MLflow est souvent déployé comme un service interne, mais exposé par commodité — pour permettre aux notebooks et aux pipelines distants de s’y connecter, parfois directement sur Internet sans authentification ni pare-feu. C’est exactement le profil que les scanners d’exploitation recherchent : une surface riche en secrets, sans les réflexes de durcissement qui protègent déjà les applications web classiques.
Ce qu’il faut faire, dans l’ordre
Le correctif est en 3.15.0. L’action minimale est la mise à jour — mais elle ne suffit pas si l’exposition demeure. Voici l’ordre des opérations :
- Mettre à jour MLflow vers 3.15.0 ou plus, sur tous les environnements (dev, staging, prod) ;
- Couper ou retirer les webhooks si vous ne les utilisez pas, et sinon restreindre l’endpoint de test aux réseaux internes ;
- Fermer l’accès réseau au serveur de tracking : jamais d’exposition directe sur Internet, toujours derrière un reverse proxy authentifié ;
- Activer IMDSv2 (et l’équivalent chez votre cloud) pour exiger un jeton de session avant toute lecture des métadonnées ;
- Réduire le rôle IAM de l’instance qui héberge MLflow au strict minimum.
# Vérifier la version déployée puis mettre à jour
pip show mlflow | grep -i version
pip install --upgrade "mlflow>=3.15.0"
# Sur AWS : vérifier qu'IMDSv2 est requis (HttpTokens=required)
aws ec2 describe-instances --instance-id i-0123456789abcdef0 \
--query "Reservations[].Instances[].MetadataOptions"La mise à jour corrige la faille ; la segmentation limite ce qu’une prochaine faille pourra atteindre. Les deux sont nécessaires, car une plateforme MLOps est par définition un carrefour de secrets — modèles, données, credentials cloud.
Verdict
Traitez CVE-2026-64849 comme un incident, pas comme une mise à jour de routine. Mettez à jour MLflow 3.15.0 dès maintenant, puis vérifiez qu’aucun serveur de tracking n’est joignable depuis Internet et que IMDSv2 est obligatoire sur les instances qui l’hébergent. Si vous ne pouvez pas patcher dans la journée, coupez immédiatement l’accès réseau au service : une SSRF lisible qui atteint l’IMDS est une clé de voûte vers votre compte cloud, pas un bug cosmétique.
Le signal plus large : la CISA commence à inscrire au KEV des failles de l’infrastructure IA. MLflow aujourd’hui, d’autres outils du stack demain. Le MLOps rejoint le périmètre de sécurité critique — et il arrive sans les réflexes de durcissement qui protègent déjà vos serveurs web.