Des équipes de veille sécurité signalent une hausse des tentatives d’exploitation contre des systèmes exposés au public. Deux vulnérabilités critiques retiennent particulièrement l’attention : MLflow SSRF (CVE-2026-64849), avec un risque d’extraction de données sensibles, et une faille affectant FUXA (CVE-2026-25895) pouvant mener à l’exécution de code à distance. L’objectif des attaquants semble clair : repérer rapidement les instances vulnérables et tenter de voler des informations de configuration ou des identifiants cloud.
Dans ce contexte, les organisations qui déploient ces logiciels doivent agir vite : corriger les versions concernées, vérifier l’exposition réseau, et analyser les journaux pour détecter d’éventuels signes de compromission.
Ce que couvre le risque MLflow SSRF (CVE-2026-64849)
La vulnérabilité MLflow SSRF identifiée sous la référence CVE-2026-64849 obtient un score CVSS de 9,3. Il s’agit d’un contournement de requêtes côté serveur (SSRF) : un attaquant, une fois en mesure d’atteindre le Tracking Server (le serveur MLflow), peut déclencher des requêtes HTTP vers des points de terminaison internes.
Le scénario d’attaque rapporté est préoccupant : les requêtes visent des services de métadonnées cloud afin d’obtenir des données sensibles. En pratique, cela peut permettre l’extraction d’informations utilisées par les applications pour s’authentifier, telles que des identifiants ou des secrets mis à disposition dans l’environnement cloud.
La vulnérabilité concerne les versions inférieures à 3.15.0. Autrement dit, toute instance MLflow non mise à jour et accessible depuis l’extérieur constitue une cible potentielle.
Comment les attaquants trouvent les instances MLflow exposées
Selon des observations indépendantes, les attaques ne reposent pas sur une pénétration sophistiquée à chaque fois. Elles s’appuient plutôt sur une méthode de repérage automatisé : scanner Internet pour identifier des instances MLflow accessibles, puis tester la surface vulnérable dès que la version et l’exposition semblent compatibles.
Les signaux rapportés indiquent que ce processus démarre peu de temps après l’attribution de la CVE. Des traces de scanning ciblant des instances MLflow exposées ont été observées « dans les heures » suivant l’annonce, ce qui suggère une exploitation précoce et une diffusion rapide de la technique.
Un point particulièrement important pour la défense est la capacité de l’attaquant à exploiter la vulnérabilité afin d’atteindre directement des services internes connus, notamment des adresses IP et services associés aux environnements cloud.
Le rôle des webhooks de registre de modèles
Au-delà du SSRF en tant que classe de faille, les retours de terrain précisent comment la chaîne d’exploitation s’appuie sur le traitement des redirections. Des experts expliquent que la faiblesse permet à un attaquant d’utiliser les webhooks liés au registre de modèles pour procurer un relais des requêtes à travers le système vulnérable.
Autrement dit, l’attaquant n’interagit pas uniquement avec une simple fonction SSRF isolée. Il cherche à tirer parti du comportement du composant exposé pour rediriger et proxyfier des requêtes vers des services internes.
Les éléments de télémétrie recueillis via des dispositifs d’observation indiquent que des acteurs abusent de cette route pour tenter d’atteindre des adresses internes et d’en extraire des informations, avec une attention portée aux services de métadonnées cloud.
Compromission : exfiltration de données et vérification des identifiants exposés
Les conséquences attendues d’un MLflow SSRF ne se limitent pas à la divulgation de données. L’objectif opérationnel semble être l’exfiltration d’éléments permettant d’accéder à l’infrastructure cloud ou à des ressources internes. Si des identifiants ou secrets sont obtenus, ils peuvent être réutilisés pour d’autres actions malveillantes : accès aux API, manipulation de services, ou mouvements latéraux.
Dans ce cadre, les recommandations formulées par les observateurs incluent la nécessité de traiter les systèmes exposés en priorité et de vérifier que des informations sensibles n’ont pas été compromises.
Les organisations sont invitées à :
- appliquer rapidement les correctifs aux versions concernées ;
- réexaminer l’exposition réseau des instances MLflow (notamment celles accessibles depuis Internet) ;
- contrôler les journaux d’audit à la recherche d’indices de compromission ;
- évaluer l’impact potentiel si des identifiants ou secrets cloud ont pu être accessibles.
En parallèle : FUXA (CVE-2026-25895) et tentatives de compromission
La seconde alerte porte sur FUXA, un logiciel open source de type SCADA/HMI orienté OT et automatisation industrielle. La vulnérabilité en cause, CVE-2026-25895, atteint un CVSS de 9,5 et combine un défaut d’authentification sur une fonction critique avec une faille de traversal de chemin (path traversal).
Le problème peut permettre à un attaquant non authentifié, distant, d’écrire des fichiers arbitraires sur le système de fichiers du serveur. Les impacts potentiels vont jusqu’à une exécution de code à distance, selon la configuration et la façon dont les fichiers sont servis ou interprétés.
La vulnérabilité concerne les versions jusqu’à 1.2.9.
Ce que montrent les signaux : scanning et tentative d’altération de fichiers
Les observations rapportent que des campagnes de scanning visant FUXA ont débuté le 18 août 2026. Un schéma de recherche à grande échelle a été mis en évidence avec un nombre limité d’installations exposées : environ 60 instances FUXA seraient accessibles publiquement.
Les tentatives de requêtes observées incluent une tentative de remplacer main.js par des données non valides via la chaîne de path traversal liée à la CVE. À ce stade des signaux, aucun chargement de payload menant explicitement à une exécution de code n’a encore été mis en évidence.
Pourquoi ces campagnes doivent être prises au sérieux
Ces deux cas partagent une dynamique : l’automatisation et la rapidité. Les attaquants repèrent des services exposés, testent la vulnérabilité et tentent d’en extraire des éléments exploitables—soit des secrets cloud, soit des fichiers pouvant ouvrir la voie à une compromission plus profonde.
Un autre facteur aggravant concerne l’évolution des correctifs et leur interaction avec les redirections. Les retours d’observation indiquent que la vulnérabilité peut rester exploitable dans certains scénarios même si des mesures antérieures avaient été prévues, ce qui rend l’audit des systèmes et la validation des mises à jour encore plus essentiels.
Plan d’action recommandé pour vos équipes
Si votre organisation déploie MLflow et/ou FUXA, voici une démarche pragmatique inspirée des recommandations mentionnées :
- Inventorier toutes les instances exposées : version logicielle, interfaces accessibles, et rôle (par exemple tracking server pour MLflow).
- Mettre à jour les composants concernés en priorité : MLflow avant 3.15.0 et FUXA avant 1.2.10.
- Réduire l’exposition : limitez l’accès aux seules sources nécessaires, et privilégiez des accès réseau contrôlés.
- Analyser les journaux : recherchez des patterns de SSRF, des tentatives vers des métadonnées cloud, et toute trace de requêtes liées aux chemins modifiés.
- Vérifier les secrets : si une exposition a eu lieu, évaluez la rotation des identifiants et la révision des permissions.
En parallèle, gardez un œil sur d’autres vulnérabilités précédemment signalées pour FUXA : des rapports font état d’efforts d’exploitation actifs sur des failles antérieures, ce qui renforce l’intérêt d’une stratégie de mise à niveau continue.
Conclusion
Le MLflow SSRF (CVE-2026-64849) illustre une menace concrète pour les environnements où des instances MLflow sont accessibles depuis Internet. En exploitant des requêtes côté serveur pour atteindre des métadonnées cloud internes, des attaquants cherchent à récupérer des secrets et des identifiants. Dans la même période, FUXA fait aussi l’objet de campagnes de scanning visant une faille critique pouvant aboutir à l’altération de fichiers et potentiellement à une exécution de code.
La réponse la plus efficace reste simple : corriger rapidement, limiter l’exposition, et auditer les logs afin de détecter les tentatives d’exploitation avant qu’elles ne se traduisent par un accès non autorisé à des données sensibles.
Source: https://thehackernews.com/2026/08/attackers-exploit-mlflow-ssrf-flaw-to.html
