Deux Outils Open Source Sont Tombés en Quelques Heures

Un Ingénieur Met en Place un Tableau de Bord, Juste Pour l'Équipe

Un ingénieur d'une entreprise de taille moyenne met en place un serveur de suivi MLflow sur une VM interne pour que l'équipe de data science puisse enregistrer des expériences et comparer des exécutions de modèles. MLflow ne demande ni nom d'utilisateur ni mot de passe lors de l'installation, donc aucun n'est configuré, et le serveur passe en ligne derrière ce que tout le monde suppose être un réseau privé. Dans une usine à quelques centaines de kilomètres de là, un ingénieur des opérations fait quelque chose de similaire : il met en place FUXA, une plateforme open source SCADA et HMI, pour donner à l'équipe une vue via navigateur des tags de la ligne de production. Aucun des deux systèmes n'a été conçu pour être accessible depuis l'internet ouvert, et aucune équipe ne l'a vérifié.

Dans la semaine du 18 août 2026, les deux suppositions se sont révélées fausses en même temps. MLflow, une plateforme de suivi d'expériences hébergée sous LF Projects à la Linux Foundation, et FUXA, un outil de systèmes de contrôle industriel totalement sans rapport, ont chacun divulgué une vulnérabilité critique, non authentifiée par défaut - et dans les deux cas, les attaquants disposaient d'exploits fonctionnels en quelques heures après la divulgation publique, pas en semaines. Deux bases de code différentes, deux secteurs différents, deux équipes qui ne se sont jamais coordonnées. Ce qu'elles partagent, c'est une seule décision de conception, prise indépendamment, à des années d'écart, pour la même raison : il est plus rapide de publier un outil avec l'authentification éteinte plutôt qu'allumée.

La Faille de MLflow Transforme une Redirection en Vol d'Identifiants

La vulnérabilité de MLflow, référencée CVE-2026-64849, obtient un score CVSS de 9,3. C'est un contournement de la validation d'URL de webhook : MLflow permet d'enregistrer des webhooks qui se déclenchent lors d'événements comme la fin d'un entraînement, et vérifie l'adresse de destination avant de l'autoriser, pour empêcher le serveur de pointer vers des adresses internes. Les attaquants ont découvert qu'ils pouvaient contourner cette vérification en combinant une redirection HTTP avec du DNS rebinding - ils enregistrent un webhook vers une adresse qui passe la validation, puis la font résoudre, au moment de la requête, vers une IP interne que le validateur n'a jamais vue. GitLab a publié un avis de sécurité sur la faille, et l'exploit a été corroboré indépendamment par des médias de cybersécurité comme cybersecuritynews, cyberpress et GBHackers.

Le gain pour un attaquant est la falsification de requête côté serveur : le serveur MLflow lui-même devient celui qui effectue la requête, depuis l'intérieur du réseau où il se trouve. Cela permet à un attaquant d'atteindre des services internes qui n'étaient jamais censés être exposés vers l'extérieur, et surtout les points de terminaison de métadonnées d'instance cloud chez AWS, Azure et GCP - les adresses internes qui délivrent des identifiants temporaires à la machine qui les demande. Comme les serveurs de suivi MLflow fonctionnent souvent sans authentification dans les déploiements réels, rien n'empêche un attaquant externe de faire cette première requête. The Hacker News a rapporté le 18 août 2026 que l'exploitation active a commencé en quelques heures après la divulgation.

La Faille de FUXA Permet à des Tiers d'Écrire des Fichiers sur les Systèmes d'Usine

FUXA est une plateforme open source SCADA et HMI - le genre de logiciel qui donne aux opérateurs d'usine une fenêtre navigateur sur les équipements qui pilotent réellement une ligne de production. Sa vulnérabilité, CVE-2026-25895, obtient un score encore plus élevé que celui de MLflow, à 9,5, et le mécanisme est plus direct : authentification manquante combinée à une faille de path traversal. Un attaquant non authentifié peut envoyer une requête qui échappe au répertoire dans lequel FUXA s'attend à écrire et placer un fichier n'importe où dans le système de fichiers sous-jacent, à son choix.

L'écriture arbitraire de fichiers n'est pas un simple bug d'exposition de données, c'est un point d'appui. Un attaquant capable d'écrire des fichiers où il veut sur un système qui communique avec des équipements industriels peut y déposer du code exécutable et obtenir l'exécution de code à distance, ce qui signifie le contrôle total de l'hôte exécutant l'HMI - et, selon la façon dont cet hôte est relié à l'atelier de production, un chemin vers les systèmes de contrôle eux-mêmes. Comme pour MLflow, The Hacker News et les mêmes médias corroborants ont rapporté que l'exploitation active avait commencé en quelques heures après la divulgation publique, la même semaine que l'avis sur MLflow.

Le Point Commun N'est Pas le Code, C'est le Réglage Par Défaut

MLflow et FUXA ne partagent ni code, ni mainteneurs, ni marché. L'un suit des expériences de machine learning, l'autre visualise des systèmes de contrôle industriel, et ils ont été divulgués indépendamment la même semaine par pure coïncidence de calendrier. Ce qu'ils partagent, c'est un réglage par défaut : publier sans authentification, parce que c'est le moyen le plus rapide de faire fonctionner un outil pour une petite équipe interne, et parce que l'équipe suppose que le réseau environnant est privé. Cette supposition constitue toute la surface d'attaque.

Ce même réglage par défaut se cache derrière une grande partie des outils internes que les dirigeants n'inspectent jamais personnellement : tableaux de bord MLOps, piles de supervision, panneaux d'administration internes, et systèmes SCADA/HMI dans toute l'industrie manufacturière. Chacun a probablement été mis en place rapidement, par quelqu'un de compétent, résolvant un problème réel, qui n'est jamais revenu activer l'authentification parce que rien ne l'y obligeait. L'écart entre ce qui est supposé privé et ce qui est réellement accessible - que ce soit par exposition directe à internet ou, comme avec MLflow, par un pivot SSRF depuis un système accessible - est exactement là où ont atterri les deux exploits, et c'est là qu'atterrira le prochain.

Quelques Heures Avant Exploitation, C'est Désormais la Vraie Fenêtre de Correctif

Pour toute entreprise de l'UE ou du Royaume-Uni qui exploite des pipelines MLOps - de plus en plus courant à mesure que les entreprises déploient leur propre infrastructure ML et IA - ou toute entreprise industrielle ou manufacturière qui exploite des systèmes SCADA ou HMI, la réponse pratique est un audit, pas une note de politique. Chaque outil interne a besoin d'une réponse directe à une question : l'authentification est-elle réellement activée, et non simplement supposée, et l'outil est-il réellement inaccessible depuis l'extérieur du réseau où il est censé se trouver ? MLflow et FUXA montrent tous deux que la réponse honnête est souvent non, et que personne ne le découvre avant l'exploitation.

L'autre ajustement concerne l'horloge. Les deux failles sont passées de la divulgation publique à l'exploitation active en quelques heures, pas dans les semaines que les cycles de correctifs supposaient traditionnellement. Pour les opérateurs industriels basés dans l'UE en particulier, ce n'est pas seulement un problème technique : les obligations NIS2 s'appliquent aux fournisseurs d'infrastructures numériques et, notamment, aux opérateurs manufacturiers et industriels exploitant des systèmes OT et SCADA, ce qui fait d'une HMI non corrigée et non authentifiée un manquement de conformité autant qu'un problème de sécurité. La solution n'a rien d'exotique - activer l'authentification, corriger le jour de la divulgation, supposer que rien derrière le pare-feu n'est réellement privé - mais elle doit intervenir avant l'exploit, et cette semaine, cet écart s'est mesuré en heures.

À lire ensuite: Une faille que votre registre DORA n'explique pas  |  Shell et Philips ont perdu des plans, pas des mots de passe