MLflow et FUXA ciblés : exploitation de failles critiques dans l’IA et l’automatisation industrielle

Scans actifs contre les serveurs MLflow et les installations FUXA

Des scans et des tentatives d’exploitation ciblent actuellement des installations exposées de MLflow, une plateforme open source de gestion des workflows de machine learning, et de FUXA, un logiciel web SCADA/HMI utilisé dans des environnements OT et industriels.

L’activité a été observée par watchTowr et VulnCheck. Pour MLflow, les scans ont commencé quelques heures après l’attribution de CVE-2026-64849, le 17 août 2026. Pour FUXA, VulnCheck a détecté une activité malveillante le 18 août 2026, avec une adresse IP recherchant systématiquement des installations accessibles depuis Internet.

Les estimations disponibles font état d’environ 60 installations FUXA exposées publiquement. Les requêtes observées tentaient d’écraser le fichier main.js en exploitant la vulnérabilité CVE-2026-25895. Aucun payload d’exécution de code n’a pour l’instant été déposé dans le cadre de cette activité, mais cette technique peut préparer une compromission complète du serveur.

Les deux plateformes présentent des profils de risque différents. MLflow peut devenir un point d’accès à des identifiants cloud et à des services internes ; FUXA peut exposer directement des systèmes d’automatisation, des équipements ICS et des processus industriels.

MLflow : une SSRF permet de lire des services internes et des métadonnées cloud

La vulnérabilité CVE-2026-64849 est une Server-Side Request Forgery, ou SSRF, non authentifiée. Elle affecte le système de distribution des webhooks du Model Registry et peut être exploitée par toute personne capable d’atteindre le Tracking Server de MLflow.

Le point de terminaison concerné est :

POST /api/2.0/mlflow/webhooks/{id}/test

Un attaquant peut contraindre le serveur à envoyer des requêtes HTTP vers des adresses loopback, des hôtes internes, des interfaces d’administration et des services de métadonnées d’infrastructures cloud. La réponse upstream est ensuite renvoyée par le point de terminaison de test, y compris le code HTTP et le contenu.

Il ne s’agit donc pas d’une SSRF « aveugle ». L’attaquant peut lire directement les données accessibles par le serveur, notamment des tokens IAM, des identifiants temporaires et d’autres secrets présents dans les services cloud. Le score indiqué dans l’archive est de CVSS 9.3, avec le vecteur suivant :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N

Le problème résulte de l’interaction de plusieurs défauts dans la gestion des destinations. La fonction _validate_webhook_url, introduite dans la version 3.10.0, résout le nom d’hôte et bloque les adresses privées, loopback, link-local ainsi que les endpoints de métadonnées. Toutefois, l’adresse vérifiée n’est pas liée à la connexion établie par la suite.

Par ailleurs, le serveur suit les redirections, car la session HTTP ne définit pas allow_redirects=False, tandis que la destination indiquée par la redirection n’est pas soumise à une nouvelle validation. Cela ouvre également la voie à des scénarios de DNS rebinding, dans lesquels l’hôte se résout vers une adresse publique lors du contrôle, puis vers une ressource interne au moment de la connexion.

Un endpoint HTTPS public peut, par exemple, répondre par une redirection 302 vers :

http://169.254.169.254/latest/meta-data/iam/security-credentials/

Des redirections 307 ou 308 sont également possibles. Elles conservent la méthode et le corps de la requête, ce qui peut permettre des variantes avec écriture vers la destination interne.

La vulnérabilité a été confirmée sur mlflow==3.13.0, avec la base de données SQLite par défaut. L’authentification n’est pas nécessaire : sur le serveur standard, les webhooks ne sont pas protégés, tandis que les contrôles d’autorisation ne sont disponibles qu’au moyen d’un plugin optionnel qui n’est pas chargé automatiquement.

Les informations relatives aux versions ne sont pas parfaitement cohérentes. Un seuil opérationnel considère comme vulnérables les versions antérieures à la 3.15.0, tandis que l’avis technique confirme l’impact sur la version 3.13.0 et les versions antérieures, sans mentionner de version corrigée dans la fiche. Le correctif est associé à la pull request #24258 et au commit ba94952247, qui introduit SSRFProtectedHTTPAdapter.

Le nouvel adaptateur vérifie l’adresse IP du socket immédiatement après la connexion et avant l’échange TLS/HTTP. Les redirections passent elles aussi par ce mécanisme protégé, ce qui empêche le contournement par redirection et le DNS rebinding.

FUXA : écriture arbitraire de fichiers et possible exécution de code

CVE-2026-25895 concerne FUXA jusqu’à la version 1.2.9 incluse. Le correctif est disponible dans la version 1.2.10.

La faille combine une path traversal et l’absence d’authentification pour une fonction critique. Un attaquant distant non authentifié peut écrire des fichiers arbitraires à des emplacements choisis sur le système de fichiers du serveur, même lorsque runtime.settings.secureEnabled est défini sur true.

Le risque inclut l’écrasement de fichiers applicatifs, de configurations et de scripts de démarrage. Si un fichier modifié est ensuite chargé ou exécuté par le système, cette écriture peut conduire à une exécution de code à distance. La gravité dépend des privilèges du processus FUXA et des connexions existantes avec les réseaux OT et les systèmes SCADA.

L’avis attribue à cette vulnérabilité un score CVSS 4.0 de 9.5, avec un impact élevé sur la confidentialité, l’intégrité et la disponibilité du système vulnérable et des systèmes en aval. L’archive mentionne également un score CVSS 3.1 de 9.8 :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Lors des scans observés, la tentative consistait à écraser main.js avec des données dépourvues de sens. L’absence de payload RCE lors de la phase observée ne réduit pas la priorité : elle montre que les attaquants atteignent déjà la fonction vulnérable et en vérifient le comportement.

Le problème est distinct de CVE-2025-69981, associée à une fonction d’upload non sécurisée. Cette fonctionnalité avait été protégée par l’authentification ; la vulnérabilité actuelle est en revanche une path traversal permettant l’écriture arbitraire.

FUXA : contournement de l’autorisation des planificateurs industriels

FUXA présente également CVE-2026-25939, un contournement de l’autorisation classé CWE-862. Les versions concernées sont celles antérieures à la 1.2.11 ; le correctif indiqué est FUXA 1.2.11.

La faille permet à un utilisateur distant non authentifié de créer ou de modifier des planificateurs arbitraires. Dans les versions 1.2.8 à 1.2.10, cette capacité peut être exploitée pour préparer des actions ultérieures contre des environnements ICS et SCADA connectés.

Le score est de CVSS 9.1 :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

La principale conséquence concerne l’intégrité et la disponibilité : un planificateur altéré peut modifier le comportement attendu des installations ou déclencher des opérations non autorisées. Aucun autre indicateur technique concernant les tentatives observées contre cette vulnérabilité n’est disponible.

L’activité visant FUXA s’inscrit dans une série plus large. L’exploitation de CVE-2023-33831, évaluée à CVSS 9.8 avec le vecteur suivant, a également été observée :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Selon les informations disponibles, cette activité aurait commencé en novembre 2025 et se serait poursuivie jusqu’à la période précédant immédiatement sa détection. Aucun détail supplémentaire sur le vecteur ou les indicateurs n’est connu.

Vérifications à effectuer et mesures pour réduire l’exposition

Les administrateurs doivent mettre à jour FUXA au minimum vers la 1.2.10 pour CVE-2026-25895 et vers la 1.2.11 pour CVE-2026-25939. Pour MLflow, il faut appliquer le correctif associé à la PR #24258 ; le seuil de mise à jour indiqué sur le plan opérationnel est la 3.15.0, tandis que la confirmation technique disponible concerne la version 3.13.0.

Lorsque cela est possible, MLflow et FUXA ne doivent pas être directement exposés sur Internet. L’accès doit être restreint au moyen d’une segmentation réseau, d’une authentification forte et de règles de pare-feu empêchant le serveur d’atteindre librement les services internes.

Pour MLflow, il convient d’analyser les journaux relatifs aux éléments suivants :

• création et modification des webhooks ;
• appels vers /api/2.0/mlflow/webhooks ;
• utilisation du point de terminaison /test ;
• redirections provenant d’hôtes HTTPS publics ;
• requêtes vers 169.254.169.254, 127.0.0.1 et les adresses RFC1918.

Il faut également vérifier les éventuels accès à des tokens IAM, des identifiants cloud, des secrets applicatifs et des services d’administration. Tout identifiant potentiellement exposé doit être révoqué et remplacé.

Sur FUXA, il est nécessaire de rechercher des requêtes contenant une path traversal, des modifications inattendues de main.js, des écritures anormales sur le système de fichiers et des changements non autorisés des planificateurs. Les systèmes connectés doivent être contrôlés afin de détecter les fichiers altérés, les nouvelles tâches planifiées ainsi que les commandes ou changements de processus imprévus.

Ces vulnérabilités ne figurent pas, à ce stade, dans le catalogue CISA KEV et aucune échéance de remédiation CISA ne leur est associée. Aucune date limite KEV spécifique n’est donc actuellement disponible.