Analyste réponse à incident
CVE-2026-64849 : la CISA a inscrit MLflow hier — 14 jours pour corriger, et ce que j’ai trouvé exposé chez 3 clients
TL;DR
- Le 19 août 2026, la CISA a inscrit CVE-2026-64849 à son catalogue des vulnérabilités activement exploitées, sous l’intitulé « MLflow Server-Side Request Forgery Vulnerability ». Échéance de correction fédérale : 2 septembre 2026.
- Note CVSS 9,3. Falsification de requête côté serveur non authentifiée et en lecture complète : l’attaquant atteint le service de métadonnées cloud et en lit la réponse — donc des identifiants temporaires valides. Toutes les versions antérieures à 3.15.0 sont concernées.
- Exploitation observée en quelques heures après l’attribution du CVE le 17 août, via les pots de miel de watchTowr. Un cycle de correctifs mensuel place votre fenêtre de correction plusieurs semaines après le début du balayage.
- Le vrai sujet n’est pas MLflow. C’est l’outillage de données installé hors du circuit d’achat, absent de l’inventaire, rarement éteint et porteur d’habilitations cloud larges. Chez nos trois clients concernés, deux avaient perdu l’équipe qui l’avait déployé.
Le 19 août 2026, l’agence américaine CISA a ajouté CVE-2026-64849 à son catalogue des vulnérabilités activement exploitées, sous l’intitulé « MLflow Server-Side Request Forgery Vulnerability ». Le catalogue porte le numéro de version 2026.08.19 et l’échéance de correction imposée aux agences fédérales est fixée au 2 septembre 2026.
Nous avons lancé la recherche chez nos clients le soir même. Sur les trois qui exploitent une plateforme de suivi d’expériences d’apprentissage automatique, trois avaient une instance MLflow joignable au-delà de leur périmètre applicatif. Aucun des trois ne la considérait comme un service exposé. Deux d’entre eux ne savaient pas qu’elle était encore allumée.
Ce n’est pas une histoire de négligence. C’est le résultat prévisible d’un outil installé par une équipe de données, en dehors du référentiel d’actifs tenu par l’informatique.
Ce que fait exactement CVE-2026-64849
La note est de 9,3 sur l’échelle CVSS 3.1, ce qui la place dans la catégorie critique. Toutes les versions de MLflow antérieures à la 3.15.0 sont concernées.
Le mécanisme est instructif parce qu’il illustre une erreur de conception que nous voyons ailleurs. MLflow expose un point d’entrée de test de webhook, POST /api/2.0/mlflow/webhooks/{id}/test, et ce point d’entrée ne demande aucune authentification.
La fonction de validation d’URL est bien présente : elle vérifie l’adresse fournie et refuse les destinations internes. Le problème est qu’elle ne vérifie que l’URL d’origine. Le module de livraison, lui, suit les redirections HTTP et résout à nouveau le nom d’hôte sans épingler l’adresse validée. Un attaquant fournit donc une URL externe parfaitement légitime, qui répond par une redirection vers un service interne — ou qui change de réponse DNS entre la validation et la requête, technique dite de réassociation DNS.
Et surtout : la réponse est renvoyée à l’appelant, avec le code de statut et le corps du message. Ce n’est donc pas une falsification de requête « aveugle » où l’attaquant devine ce qui se passe. C’est une falsification en lecture complète : il voit le contenu.
Notre avis d’expert (1/3)
Le détail qui fait la différence entre « préoccupant » et « urgent » est la lecture complète de la réponse. Une falsification aveugle contre un service de métadonnées cloud oblige l’attaquant à travailler à l’estime. Ici, il interroge le service de métadonnées de l’instance et il en lit la réponse — c’est-à-dire, très concrètement, des identifiants temporaires valides. Le chemin entre « une instance MLflow oubliée est joignable » et « un tiers dispose de jetons de votre compte cloud » ne comporte aucune étape intermédiaire difficile. C’est ce qui explique la vitesse de l’exploitation observée.
Une exploitation en quelques heures, pas en quelques semaines
La chronologie mérite d’être posée, parce qu’elle contredit l’intuition habituelle sur les délais de correction.
L’identifiant CVE a été attribué le 17 août 2026. Le réseau mondial de pots de miel de watchTowr a observé, dans les heures qui ont suivi, des acteurs balayant Internet à la recherche d’instances MLflow exposées, dans le but de récupérer des identifiants cloud et des jetons de déploiement. Le 19 août, la CISA inscrivait la vulnérabilité au catalogue des failles activement exploitées.
Deux jours entre l’attribution de l’identifiant et l’inscription officielle au catalogue. Pour une organisation qui applique un cycle de correctifs mensuel, cela signifie que le balayage a précédé de plusieurs semaines la fenêtre de correction prévue.
Chronologie CVE-2026-64849 — de l’attribution à l’inscription au catalogue CISA
Pourquoi votre PME est probablement concernée sans le savoir
MLflow est un outil de suivi d’expériences d’apprentissage automatique. Il n’est presque jamais déployé par une direction informatique. Il est installé par un profil data, souvent pour un projet précis, souvent avec la meilleure des intentions : garder trace des paramètres et des résultats d’entraînement.
Trois caractéristiques en font une cible idéale, et elles sont cumulatives.
Il n’est pas dans votre inventaire. Il n’a pas été commandé, pas facturé, pas déclaré. Une recherche par nom dans votre référentiel d’actifs ne le trouvera pas.
Il vit à côté des identifiants qui comptent. Une plateforme d’entraînement a besoin d’accéder au stockage objet, au registre de conteneurs, parfois à la base de production en lecture. Les habilitations attachées à la machine qui l’héberge sont, par nature, larges.
Il est rarement éteint. Le projet se termine, l’instance reste. Chez deux de nos trois clients, l’équipe qui l’avait déployée n’était plus dans l’entreprise.
Notre avis d’expert (2/3)
Cette faille est intéressante moins pour elle-même que pour ce qu’elle révèle. La question à poser en comité cette semaine n’est pas « avons-nous MLflow ? » — c’est « quels autres outils tournent chez nous sans figurer dans l’inventaire, avec des habilitations cloud attachées ? ». La réponse comprend presque toujours un carnet de notes interactif, une interface de suivi d’entraînement, un tableau de bord de données interne et un outil d’orchestration. Le sujet n’est pas l’intelligence artificielle : c’est que l’outillage de données s’installe hors du circuit d’achat habituel, et que le circuit d’achat était votre inventaire de fait.
Savez-vous ce qui est joignable depuis Internet chez vous ?
Nous cartographions votre surface exposée réelle — y compris les services installés hors du circuit informatique — et vous livrons la liste priorisée par exploitabilité.
Discutons-enCe qu’il faut faire avant le 2 septembre
La correction est simple et disponible : passer en MLflow 3.15.0 ou supérieur. La difficulté n’est pas le correctif, c’est de trouver les instances.
1. Chercher par comportement, pas par nom. Balayez votre plage d’adresses publiques et vos réseaux internes à la recherche des ports habituels de l’outil, puis vérifiez la présence du chemin d’API caractéristique. Un inventaire fondé sur les noms d’actifs déclarés ne trouvera rien.
2. Regarder les journaux avant de corriger. Cherchez les appels au point d’entrée de test de webhook dans les journaux d’accès, sur les trois dernières semaines. Une requête réussie vers ce chemin depuis une adresse externe est un incident, pas une alerte à trier. Corriger d’abord et enquêter ensuite vous prive de la preuve.
3. Faire tourner les identifiants attachés à la machine. Si l’instance était joignable et que les journaux ne permettent pas de conclure, considérez les identifiants attachés au rôle de cette machine comme compromis. Leur rotation coûte quelques heures ; l’hypothèse inverse coûte beaucoup plus.
4. Bloquer l’accès au service de métadonnées depuis les charges applicatives. C’est la mesure qui aurait neutralisé cette faille indépendamment du correctif, et elle protège aussi contre les prochaines. Toutes les grandes offres cloud proposent aujourd’hui un mode d’accès aux métadonnées exigeant un jeton, et il n’est pas activé par défaut sur les instances anciennes.
Chemin d’attaque complet — et les trois endroits où il se coupe
Notre avis d’expert (3/3)
Une remarque sur l’échéance du 2 septembre : elle n’a aucune valeur juridique pour une entreprise française. Elle contraint les agences fédérales américaines. Nous la citons quand même dans nos rapports, et nos clients la reprennent, parce qu’elle constitue une date opposable produite par un tiers — et qu’une date opposable est ce qui manque le plus souvent à une équipe technique pour obtenir un créneau de correction. Dans le cadre de la directive NIS2, ce type d’inscription entre par ailleurs directement dans la démonstration qu’une organisation surveille les vulnérabilités connues et applique des délais définis. La question posée en audit n’est pas « avez-vous corrigé ? » mais « comment avez-vous su, et en combien de temps ? ».
Le lien avec la conformité, sans le jargon
Si votre organisation relève de NIS2, cette semaine est un cas d’école utile à documenter. Le référentiel attend une gestion des vulnérabilités qui soit un processus, pas une réaction : une source de veille identifiée, un délai de traitement défini par niveau de criticité, et une trace de la décision.
Trois éléments à conserver dans votre dossier : la date à laquelle vous avez eu connaissance de l’inscription, la date à laquelle vous avez terminé la recherche d’instances, et la décision motivée pour chaque instance trouvée. Trois lignes dans un tableau. Elles valent plus, en audit, qu’une politique de correctifs de quinze pages que personne n’applique.
Pour cadrer ce qui relève réellement du périmètre, voir notre page dédiée à l’audit de périmètre NIS2.
Pour aller plus loin
La question de fond — un outil de données installé hors circuit, avec de larges habilitations — est autant un sujet d’architecture que de sécurité. Nos confrères de D-Open traitent régulièrement la gestion des dépendances et des services internes côté développement. Et si votre plateforme d’apprentissage automatique est en production plutôt qu’en expérimentation, Plug-Tech couvre bien le sujet de l’exploitation des plateformes d’intelligence artificielle en PME.
Questions fréquentes
Le risque baisse fortement mais ne disparaît pas, et il faut être précis sur ce que « interne » recouvre. La faille permet d’atteindre des services que le serveur MLflow peut joindre, pas ceux que l’attaquant peut joindre. Une instance strictement interne exige donc que l’attaquant ait déjà un pied dans le réseau — ce qui en fait un excellent outil de déplacement latéral et d’escalade, mais pas un point d’entrée initial. Corrigez-la quand même, en la traitant comme importante plutôt qu’urgente, et vérifiez surtout que « interne » signifie bien inaccessible depuis Internet, ce qui n’est pas toujours le cas des instances déployées dans un cloud public avec un groupe de sécurité permissif.
Cherchez dans les journaux d’accès du serveur les requêtes de type POST vers le chemin de test de webhook, sur au moins les trois dernières semaines. Une requête aboutie depuis une adresse externe doit être traitée comme un incident. Regardez ensuite du côté cloud : recherchez l’utilisation d’identifiants attachés au rôle de la machine depuis des adresses inhabituelles, sur la même période. Faites cette vérification avant d’appliquer le correctif, car la mise à jour ne détruit pas les journaux mais l’enquête devient nettement plus difficile une fois l’instance redéployée.
Elle clôt cette vulnérabilité précise. Elle ne clôt pas la situation qui l’a rendue exploitable, à savoir un service installé hors inventaire, joignable, et porteur d’habilitations cloud larges. Les deux mesures qui vous protégeront de la prochaine faille du même type sont indépendantes du correctif : retirer l’exposition réseau des services qui n’ont pas besoin d’être joignables, et exiger un jeton pour l’accès au service de métadonnées de vos instances. La seconde neutralise à elle seule toute une famille de falsifications de requête côté serveur.
Trois informations suffisent et elles tiennent en trois lignes de tableau : la date à laquelle vous avez eu connaissance de l’inscription au catalogue des vulnérabilités exploitées, la date à laquelle la recherche d’instances a été terminée dans votre parc, et la décision motivée pour chaque instance trouvée — corrigée, retirée du réseau, ou acceptée avec justification et échéance. Ce qui est évalué en audit n’est pas la rapidité absolue mais l’existence d’un processus traçable et le respect du délai que vous avez vous-même fixé.
Vous ne trouvez pas la réponse à votre question ?
Une instance oubliée suffit à donner vos identifiants cloud.
Nous cartographions votre surface exposée réelle, journaux à l’appui, et vous livrons la liste des services joignables classés par exploitabilité — avec la trace exploitable en dossier NIS2. Téléphone : +33 6 32 64 24 80.
Discutons-enVeille cybersecurite
Recevez chaque semaine les dernieres menaces, vulnerabilites et bonnes pratiques directement dans votre boite mail.
Pas de spam. Desinscription en un clic. Environ 1 email par semaine.
— Pret a renforcer votre cybersecurite ?
Rejoignez les entreprises qui font confiance a WebGuard Agency pour proteger leurs actifs numeriques. Premier audit offert.