Sécuriser MLflow est devenu une urgence pour toute PME-ETI qui expérimente l’IA : une faille SSRF (CVE-2026-64849) est activement exploitée pour voler les identifiants cloud des serveurs MLflow exposés. Les attaquants ont commencé à scanner quelques heures seulement après l’attribution du CVE. Ce tutoriel détaille les étapes concrètes pour auditer, durcir et surveiller votre plateforme MLOps avant qu’elle ne devienne la porte d’entrée de votre compte cloud.
Pourquoi sécuriser MLflow est une priorité en 2026
MLflow est le registre de modèles le plus déployé dans les équipes data. Le problème n’est pas le produit, c’est la façon dont il est installé : dans la majorité des cas, un serveur de tracking lancé « pour tester », sans authentification, sur une instance cloud qui porte un rôle IAM généreux. C’est exactement la configuration que la faille exploite.
Le mécanisme est simple. La vulnérabilité de type SSRF (Server-Side Request Forgery) permet à un attaquant non authentifié de forcer le serveur MLflow à émettre une requête HTTP vers une adresse interne de son choix. La cible privilégiée est le service de métadonnées de l’instance — 169.254.169.254 sur AWS, GCP et Azure — qui renvoie des jetons d’accès temporaires valides. L’attaquant n’a pas besoin d’un exploit mémoire ni d’une exécution de code : il demande poliment au serveur de lui rapporter les clés.
La conséquence pour une PME-ETI est disproportionnée par rapport à l’importance apparente de l’actif. Un serveur d’expérimentation IA, souvent hors du périmètre de supervision, devient un pivot vers les buckets de données, les bases de production et parfois l’ensemble du compte cloud. C’est le même schéma que celui décrit dans notre article sur la protection des assistants IA internes : l’outillage IA est déployé plus vite qu’il n’est gouverné.
Étape 1 — Inventorier vos serveurs MLflow exposés
Avant tout durcissement, il faut savoir ce qui tourne. La plupart des instances vulnérables sont inconnues de l’équipe sécurité parce qu’elles ont été lancées par une équipe data.
- Recensez les ports 5000 et 5001 ouverts sur votre plage d’adresses interne et sur vos IP publiques.
- Interrogez vos APIs cloud : instances taguées
ml,datascience,experiment, groupes de sécurité autorisant0.0.0.0/0. - Vérifiez les conteneurs :
docker ps --format '{{.Image}} {{.Ports}}' | grep -i mlflow. - Recherchez les déploiements Kubernetes :
kubectl get svc -A | grep -i mlflowet repérez les services de typeLoadBalancer.
Testez ensuite l’exposition réelle depuis l’extérieur. Si curl -s http://VOTRE_IP:5000/api/2.0/mlflow/experiments/search répond sans authentification, l’instance est ouverte à Internet.
Étape 2 — Corriger la faille et couper la route vers les métadonnées
Le correctif éditeur est la première action, mais il ne suffit pas : d’autres SSRF apparaîtront. La défense durable consiste à rendre le service de métadonnées inatteignable depuis l’application.
Appliquer le correctif
Mettez à jour vers la dernière version corrigée du serveur de tracking, y compris dans vos images de base et vos requirements.txt. Une image applicative reconstruite chaque nuit reste vulnérable si la version est épinglée.
Forcer IMDSv2 et bloquer l’accès aux métadonnées
- AWS : imposez IMDSv2 (
HttpTokens=required) et réduisezHttpPutResponseHopLimità 1. IMDSv2 exige un jeton obtenu par requête PUT, ce qu’une SSRF classique en GET ne peut pas produire. - Azure et GCP : exigez l’en-tête
Metadata: true/Metadata-Flavor: Google, non injectable par une SSRF simple. - Ajoutez une règle de pare-feu locale bloquant explicitement la sortie vers
169.254.169.254depuis le processus applicatif.
Réduire le rôle IAM
Un serveur d’expérimentation n’a pas besoin d’un accès en écriture à l’ensemble de vos buckets. Limitez le rôle à l’unique bucket d’artefacts, en lecture-écriture sur un préfixe précis. Si un jeton fuit malgré tout, le rayon d’action reste contenu.
Étape 3 — Authentifier et isoler la plateforme MLOps
Pour sécuriser MLflow durablement, le serveur ne doit jamais être joignable directement. Placez-le derrière un reverse proxy qui porte l’authentification et le chiffrement.
- Terminaison TLS et authentification déléguée à votre fournisseur d’identité (OIDC/SAML), avec MFA obligatoire.
- Accès réseau restreint au VPN d’entreprise ou à un tunnel privé — jamais d’exposition publique, même « temporaire ».
- Segmentation : le sous-réseau MLOps ne doit pas atteindre les bases de production ni le réseau bureautique.
- Comptes de service distincts pour l’entraînement, l’inférence et l’interface utilisateur, avec des permissions différentes.
Étape 4 — Détecter l’exploitation dans vos journaux
La chaîne d’attaque laisse des traces exploitables. Ces règles de détection méritent d’être ajoutées immédiatement à votre SIEM.
- Sortie vers le service de métadonnées : toute connexion vers
169.254.169.254initiée par un processus Python applicatif est anormale. C’est le signal le plus fiable. - Paramètres d’URI suspects : requêtes MLflow contenant
http://,file://ou une adresse IP littérale dans un champ d’artefact ou de source. - Utilisation de jetons hors instance : dans CloudTrail ou l’équivalent, un appel API utilisant les identifiants du rôle d’instance depuis une adresse IP externe est un indicateur de compromission fort. Activez GuardDuty InstanceCredentialExfiltration.
- Balayage : rafales de requêtes non authentifiées sur
/api/2.0/mlflow/depuis une même source.
Sur notre plateforme, ces détections sont intégrées à la supervision continue de l’Agentic SOC ucyber.ai, avec CrowdStrike Falcon comme capteur sur les hôtes : la corrélation entre le comportement du processus et l’usage anormal du jeton cloud détecte l’exfiltration même sans signature connue.
Étape 5 — Réagir si l’instance était exposée
Si l’audit révèle une exposition antérieure au correctif, considérez les identifiants comme compromis jusqu’à preuve du contraire :
- Révoquez et faites tourner le rôle IAM de l’instance, ainsi que toute clé statique stockée dans les variables d’environnement.
- Recherchez dans les journaux cloud, sur les 90 derniers jours, les appels effectués avec ce rôle depuis une IP inconnue.
- Vérifiez l’intégrité du registre de modèles : un artefact modifié est une porte dérobée qui sera déployée en production par votre propre pipeline.
- Reconstruisez l’instance à partir d’une image saine plutôt que de la nettoyer.
Ce qu’il faut retenir
Sécuriser MLflow n’est pas un chantier data, c’est un chantier d’exposition. La faille SSRF CVE-2026-64849 rappelle une règle simple : tout service qui tourne sur une instance porteuse d’un rôle cloud doit être traité comme un composant critique, quel que soit son statut « expérimental ». L’inventaire, IMDSv2, le moindre privilège et la détection des appels vers le service de métadonnées couvrent l’essentiel du risque — et protègent au passage tous les autres outils MLOps qui subiront la même classe d’attaque. Le sujet rejoint directement celui de la sécurisation des portails SaaS : la donnée fuit rarement par un exploit sophistiqué, bien plus souvent par un accès que personne n’a pensé à restreindre.