RCE non authentifiée sur les serveurs de tracking MLflow (CVE-2026-116692)

Résumé (TL;DR)

• La CVE-2026-116692 est une exécution de code à distance (RCE) sur le serveur de tracking de machine learning de MLflow lui-même : tout appelant HTTP capable de joindre le serveur peut téléverser un module Python et faire en sorte que le serveur l'importe et l'exécute, sans identifiants sur un déploiement par défaut. Le bulletin de sécurité GitHub lui attribue la sévérité Critical, CVSS v3.1 9,8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
• Les versions 3.12.0 à 3.16.x de MLflow sont concernées, ainsi que la release candidate 3.12.0rc0. La première version corrigée est la 3.17.0, publiée le 7 octobre 2026.
• La faille est une chaîne : la désérialisation des scorers tiers par le serveur accepte tout chemin de module qui commence par un préfixe de package autorisé, et les propres endpoints d'expériences et d'artefacts du serveur permettent à un appelant de faire pointer l'emplacement des artefacts d'une expérience vers un tel package, puis d'y téléverser un fichier Python. Les scorers sont les fonctions d'évaluation de MLflow pour les sorties d'applications LLM et d'agents, et les scorers tiers encapsulent les métriques de bibliothèques telles que Ragas, DeepEval, TruLens et Phoenix. Dans l'image officielle MLflow v3.14.0, le processus s'exécute en tant que root, si bien que le code s'exécute en tant que root.
• Aucune exploitation dans la nature n'est connue et la CVE ne figure pas dans le catalogue KEV de la CISA. Une preuve de concept inoffensive est jointe au bulletin de sécurité.
• Mettez à jour vers la 3.17.0 et recréez tous les conteneurs du serveur. Si vous ne pouvez pas mettre à jour aujourd'hui, limitez qui peut joindre le serveur : l'authentification basique n'arrête pas un utilisateur authentifié capable de créer des expériences et de téléverser des artefacts.

Suis-je concerné ?

Vous êtes concerné si vous administrez un serveur de tracking MLflow de la version 3.12.0 jusqu'à la 3.17.0 non incluse, joignable en HTTP par des appelants qui ne devraient pas pouvoir créer d'expériences ni téléverser d'artefacts, et dont le processus peut écrire dans l'un de ses packages de scorers installés. Les trois conditions suivantes doivent être réunies :

• Vous administrez un serveur de tracking MLflow en version 3.12.0 (release candidates comprises) ou ultérieure, inférieure à 3.17.0. La fonctionnalité de scorers tiers qui porte la faille apparaît pour la première fois dans la 3.12.0.
• Les endpoints HTTP du serveur (expériences, runs, téléversement d’artefacts et invocation de scorers) sont accessibles à des appelants non fiables. L’authentification est désactivée par défaut, et mlflow server écoute sur 127.0.0.1 sauf s’il est lancé avec un autre --host, comme 0.0.0.0. Un serveur qui écoute au-delà de l’interface de bouclage, ou auquel un proxy transmet des requêtes, expose ces endpoints à toute personne capable d’atteindre son port. Avec l’authentification basique activée, l’exposition se réduit aux utilisateurs authentifiés capables de créer des expériences et des runs, et de téléverser des artefacts.
• Le processus serveur peut écrire sous l'un de ses packages de scorers installés. Le bulletin indique que c'est le cas dans l'image officielle MLflow et dans les environnements virtuels installés et exécutés par le même utilisateur du système d'exploitation ; un système de fichiers de conteneur en lecture seule ou un répertoire de package de scorers dans lequel le processus serveur ne peut pas écrire bloque cette chaîne de placement précise.

Pour donner un ordre de grandeur, PyPI a enregistré 4 880 597 téléchargements de mlflow au cours de la semaine précédant le 28 octobre 2026 ; ce chiffre compte tous les téléchargements, pas seulement les serveurs de tracking.

Interrogez d’abord le serveur en cours d’exécution, puis comparez sa version au package installé dans ce déploiement. Les métadonnées du package ne prouvent pas qu’un processus a redémarré après une mise à jour :

# Running server process (include your deployment authentication if required)
curl -fsS http://<server>:<port>/version

# Installed package: run inside the deployment with the server interpreter/user
docker exec <container> python -c "import mlflow; print(mlflow.__version__)"
python -c "import mlflow; print(mlflow.__version__)"

# On-disk package metadata only; this does not inspect the running process
python -m pip show mlflow | grep Version

# Dependency files (the advisory lists only the mlflow package, not mlflow-skinny)
grep -iE "^mlflow([^a-z0-9._-]|$)" requirements*.txt
grep -A10 '"mlflow"' Pipfile.lock | grep '"version"'

Comment corriger ?

Mettez à niveau le package du serveur vers la 3.17.0 et recréez les conteneurs du serveur, afin que le processus en cours d'exécution soit remplacé, et pas seulement l'image sur le disque :

pip install -U "mlflow>=3.17.0"

pip install -U ne remplace que les fichiers sur le disque : un processus serveur lancé avant la mise à niveau garde le code vulnérable en mémoire jusqu'à son redémarrage. Redémarrez le processus serveur (par exemple avec systemctl restart sur son unité, ou l'équivalent de votre gestionnaire de processus), puis demandez sa version au serveur en cours d'exécution via son endpoint /version. Elle doit être 3.17.0 ou ultérieure :

curl -s http://<server>:<port>/version

Pour un serveur conteneurisé, changez le tag de l'image, récupérez-la et recréez le conteneur ; un ancien conteneur simplement redémarré conserve l'ancien code. Lancez ensuite la vérification de version docker exec ci-dessus sur le nouveau conteneur : elle doit afficher 3.17.0 ou une version ultérieure.

La même version corrige aussi deux vulnérabilités associées :

• CVE-2026-116690 : lecture arbitraire de fichiers sur les serveurs non authentifiés, via le chemin source d'une version de modèle étiquetée comme prompt (CVSS v3.1 7,5, concerne les versions 3.10.0 à 3.16.x) ; la FAQ ci-dessous en explique le mécanisme.
• CVE-2026-116691 : l'autologging de CrewAI enregistre les clés d'API des fournisseurs de LLM dans les spans de traces journalisés (CVSS v3.1 6,5, concerne les versions 2.19.0 à 3.16.x).

Si vous ne pouvez pas mettre à niveau aujourd'hui, trois mesures d'atténuation réduisent la fenêtre d'exposition, chacune avec ses limites :

• Restreindre l'accessibilité réseau du serveur de tracking (écoute sur l'interface de loopback, VPN, ingress avec authentification ou liste d'adresses IP autorisées). Limite : cela réduit la surface d'attaque mais ne corrige rien ; tout appelant situé à l'intérieur du périmètre peut toujours exploiter l'endpoint.
• Activer l'authentification basique de MLflow. Limite : l'endpoint d'invocation des scorers n'est pas protégé par un contrôle d'autorisation propre à la ressource, si bien qu'un principal authentifié ayant accès aux expériences, aux runs et aux artefacts reste une menace.
• Exécuter le serveur avec un système de fichiers de conteneur en lecture seule, ou avec des répertoires de packages de scorers dans lesquels le processus serveur ne peut pas écrire. Limite : cela bloque cette chaîne de placement de fichiers précise ; cela ne corrige pas le comportement de désérialisation sous-jacent.

Quelle est la cause racine ?

Le désérialiseur de scorers traite un préfixe de chaîne comme une frontière de provenance, puis importe le module nommé par la requête, quel qu'il soit, alors que les propres endpoints d'artefacts du serveur permettent à un appelant de placer un module à l'intérieur de cette frontière. MLflow 3.12.0 a introduit la prise en charge de l'enregistrement et de la désérialisation des scorers tiers dans la version open source de MLflow (commit 02eea260, pull request #22634). Au commit de la version v3.14.0, mlflow/genai/scorers/scorer_utils.py définit les racines autorisées :

THIRD_PARTY_SCORER_ALLOWED_MODULES = frozenset({
    "mlflow.genai.scorers.ragas",
    "mlflow.genai.scorers.deepeval",
    "mlflow.genai.scorers.trulens",
    "mlflow.genai.scorers.phoenix",
})

Dans mlflow/genai/scorers/base.py, le désérialiseur accepte soit une racine exacte, soit n'importe quel descendant, puis effectue trois opérations avec des valeurs contrôlées par la requête :

module_path == m or module_path.startswith(m + ".")
...
module = importlib.import_module(module_path)
scorer_class = getattr(module, class_name, None)
scorer_instance = scorer_class(**init_kwargs)

Un préfixe de nom de package n'est pas une frontière de provenance. Si le processus serveur peut écrire sous un package autorisé, un descendant créé par l'attaquant passe le contrôle de chaîne et devient du code importable.

L'autre moitié de la chaîne est l'organisation des artefacts. L'endpoint de création d'expérience accepte un artifact_location, et MLflow en dérive le répertoire d'artefacts de chaque run sous la forme <artifact_location>/<run_id>/artifacts/. Dans l'image officielle MLflow v3.14.0, un appelant peut définir l'emplacement des artefacts d'une expérience à file:///usr/local/lib/python3.10/site-packages/mlflow/genai/scorers/trulens. L'appelant téléverse ensuite un module via l'endpoint d'artefacts de run, et le fichier se retrouve au chemin d'import mlflow.genai.scorers.trulens.<run_id>.artifacts.<module>, à l'intérieur du préfixe autorisé.

Enfin, dans mlflow/server/handlers.py, _invoke_scorer_handler() désérialise et construit le scorer avant de valider ou de résoudre les identifiants de traces fournis, si bien que le constructeur contrôlé par l'attaquant s'exécute en premier. Lorsque l'authentification est désactivée, comme dans la configuration par défaut reproduite, aucun identifiant n'est nécessaire.

Comment la faille est-elle exploitée ?

Un appelant qui peut joindre le serveur utilise les propres endpoints d'expériences, de runs et d'artefacts de MLflow pour écrire un module Python dans un package de scorers autorisé, puis fait importer ce module par la route d'invocation des scorers, qui construit une classe à partir de celui-ci. La preuve de concept jointe au bulletin enchaîne ces endpoints, de bout en bout :

1. Créer une expérience dont l'artifact_location pointe vers un package de scorers autorisé et accessible en écriture, par exemple file:///usr/local/lib/python3.10/site-packages/mlflow/genai/scorers/trulens dans l'image officielle.
2. Créer un run, ce qui amène MLflow à allouer <artifact_location>/<run_id>/artifacts/.
3. Téléverser un module Python, audit_<token>.py, dans ce répertoire d'artefacts du run via l'endpoint de téléversement d'artefacts de run.
4. Soumettre un scorer tiers sérialisé dont le chemin module résout vers le fichier téléversé : mlflow.genai.scorers.trulens.<run_id>.artifacts.audit_<token>.
5. Déclencher l'import et la construction de la classe via POST /ajax-api/3.0/mlflow/scorer/invoke.

Le constructeur contrôlé par l'attaquant s'exécute alors dans le processus serveur MLflow. Dans la preuve de concept (PoC), le constructeur écrit un fichier marqueur aléatoire à côté de son propre artefact téléversé, puis la PoC télécharge ce fichier via l'endpoint d'artefacts de run et vérifie qu'il correspond exactement, ce qui prouve l'exécution. L'échec ultérieur du traitement des traces et l'erreur HTTP 500 surviennent après l'exécution du constructeur : l'erreur 500 ne réfute donc pas l'exploitation.

La reproduction à distance du bulletin a exécuté la même chaîne contre un hôte cloud jetable faisant tourner l'image officielle v3.14.0, épinglée par son digest de manifeste, avec un processus s'exécutant sous l'uid 0 et un fichier marqueur indiquant whoami: root.

Que peut faire un attaquant ?

Sur le déploiement standard sans authentification reproduit, tout appelant réseau qui joint le serveur de tracking exécute du code Python en tant que processus MLflow, sans identifiants et sans interaction utilisateur. Le bulletin détaille l'étendue des dégâts : un impact total sur la confidentialité, l'intégrité et la disponibilité de l'ensemble des données, identifiants, accès réseau et emplacements du système de fichiers accessibles au processus serveur. L'image officielle exécute le processus en tant que root, ce qui aggrave l'impact au niveau du conteneur ; l'impact sur l'hôte dépend toujours de la configuration du runtime de conteneurs, des chemins montés, des capabilities accordées et de l'exposition des sockets.

Aucun exploit prêt à l'emploi n'est public au 28 octobre 2026.

Pourquoi le correctif fonctionne-t-il ?

Le correctif, le commit a732443e (« Match third-party scorer modules exactly instead of by package prefix », pull request #25906, fusionné le 16 septembre 2026), remplace la correspondance par préfixe par une correspondance exacte :

-            if not any(
-                module_path == m or module_path.startswith(m + ".")
-                for m in THIRD_PARTY_SCORER_ALLOWED_MODULES
-            ):
+            if module_path not in THIRD_PARTY_SCORER_ALLOWED_MODULES:

La liste d'autorisation elle-même s'est étoffée pour nommer textuellement chaque module de scorer concret, par exemple mlflow.genai.scorers.ragas.scorers.rag_metrics, afin que les imports légitimes continuent de fonctionner. Un descendant placé par l'appelant, tel que mlflow.genai.scorers.trulens.<run_id>.artifacts.audit_<token>, ne correspond plus à aucune entrée de la liste : la chaîne de placement d'artefacts est donc rompue. Trois contrôles supplémentaires bloquent les autres chemins d'import qu'une requête pourrait atteindre :

• metric_name doit être un identifiant Python simple, car les wrappers de scorers Ragas et DeepEval de MLflow résolvent les noms de métriques inconnus en les insérant dans un chemin d'import tel que ragas.metrics.collections.<metric_name> ou deepeval.metrics.<metric_name>.
• kwargs ne peut pas écraser le metric_name validé.
• Après l'import, la classe récupérée doit être une sous-classe de Scorer avant d'être instanciée.

Ensemble, ces mesures font que le désérialiseur n'importe que les modules livrés par MLflow lui-même, ce que prévoyait la conception d'origine.

Comment vérifier si j'ai été compromis ?

Les documents publiés décrivent la preuve de concept, pas des indicateurs liés à un attaquant : il n'existe donc aucune liste publique d'indicateurs. À partir du fonctionnement décrit dans le bulletin lui-même, un déploiement concerné peut rechercher les traces que laisse la chaîne :

• Recherchez les fichiers .py présents dans les packages de scorers installés et plus récents que le fichier __init__.py de MLflow. Lancez les commandes avec l'interpréteur du serveur, afin que $MLFLOW_ROOT soit le chemin depuis lequel le serveur importe ses modules :

# Files placed inside installed scorer packages (run with the server's interpreter)
MLFLOW_ROOT=$(python -c "import mlflow, os; print(os.path.dirname(mlflow.__file__))")
find "$MLFLOW_ROOT/genai/scorers/" -type f -name '*.py' -newer "$MLFLOW_ROOT/__init__.py"

• Auditez le tracking store à la recherche d'expériences dont l'artifact_location est un chemin file:// situé dans l'installation Python, en particulier sous site-packages/mlflow/genai/scorers/ ; la preuve de concept utilise exactement ce schéma. Sur un backend store SQL, interrogez la table experiments (l'exemple SQLite ci-dessous fonctionne de la même façon avec psql ou mysql) ; sur un store mlruns à base de fichiers, le meta.yaml de chaque expérience contient son artifact_location :

# Experiments whose artifact location points into the scorer packages
sqlite3 mlflow.db "SELECT experiment_id, name, artifact_location FROM experiments WHERE artifact_location LIKE '%/mlflow/genai/scorers%';"
grep -l 'mlflow/genai/scorers' mlruns/*/meta.yaml

• Recherchez dans les journaux d'accès du serveur les requêtes POST vers /ajax-api/3.0/mlflow/scorer/invoke dont le contenu porte third_party_scorer_data avec un chemin module contenant un segment .artifacts.. La chaîne produit toujours un chemin de la forme mlflow.genai.scorers.<package>.<run_id>.artifacts.<module>, l'identifiant de run de 32 caractères hexadécimaux précédant directement .artifacts., et aucun module livré par MLflow ne contient ce segment.
• Recherchez dans les journaux d'accès du serveur les téléversements de fichiers .py. La route de téléversement d'artefacts de run de MLflow, POST /ajax-api/2.0/mlflow/upload-artifact, reçoit le nom du fichier de destination dans son paramètre de requête path, ce qui permet cette vérification même après la suppression du fichier téléversé :

grep -E 'POST /ajax-api/2\.0/mlflow/upload-artifact\?[^ ]*path=[^ &]*\.py' access.log

Une revue des journaux sans anomalie n'offre qu'une faible garantie, en particulier si le serveur a fonctionné avec l'authentification désactivée sur un réseau ouvert, pendant une période quelconque, dans une version concernée. Chaque étape passe par les propres endpoints d'expériences, de runs, d'artefacts et de scorers de MLflow, si bien qu'aucune requête ne vise un endpoint inhabituel, et que seuls des détails comme ceux ci-dessus distinguent ces requêtes d'un usage légitime. Les traces qui persistent sont l'enregistrement de l'expérience avec son artifact_location en file:// et le répertoire du run contenant le module téléversé. Dans la preuve de concept, un fichier marqueur se trouve aussi à côté du module. Du code s'exécutant en tant que processus serveur peut supprimer toutes ces traces.

Si vous trouvez l'une de ces traces, considérez le serveur comme compromis au lieu de simplement le mettre à niveau sur place. Le bulletin inclut dans le périmètre toutes les données, tous les identifiants, tous les accès réseau et tous les emplacements du système de fichiers accessibles au processus serveur : isolez donc le serveur, renouvelez chaque identifiant que ce processus pouvait lire et recréez-le à partir d'une image propre en 3.17.0 ou ultérieure.

Chronologie

• 2026-07-12 : la sortie expurgée de la reproduction à distance du bulletin enregistre cette date comme heure du serveur, et le bulletin indique qu'aucune version corrigée n'était identifiée à cette date (bulletin GitHub, transcription de la preuve de concept).
• 2026-09-16 : fusion du commit de correctif a732443e dans master via la pull request #25906 : correspondance exacte des modules, plus les contrôles sur l'identifiant, les kwargs et la sous-classe (commit GitHub).
• 2026-10-07 : publication de MLflow 3.17.0 avec le correctif (releases GitHub).
• 2026-10-09 : MLflow publie le bulletin de sécurité du dépôt GHSA-26p8-2jq9-3vq9 (08:20 UTC), qui classe la faille Critical, CVSS v3.1 9,8 (bulletin de sécurité GitHub).
• 2026-10-27 : la GitHub Advisory Database référence GHSA-26p8-2jq9-3vq9 (21:26 UTC).
• 2026-10-28 : cet article.

Le correctif lui-même est arrivé plus de deux mois après la reproduction de juillet. Pour un serveur concerné, exposé depuis juillet et non mis à niveau le 7 octobre, les seuls signaux publics avant le bulletin du 9 octobre étaient le commit de correctif du 16 septembre et une entrée d'une ligne dans les notes de version de la 3.17.0, tous deux intitulés « Match third-party scorer modules exactly instead of by package prefix (GHSA-26p8-2jq9-3vq9) ». Les scanners de dépendances sont restés muets plus longtemps encore : les alertes Dependabot s'appuient sur la GitHub Advisory Database, qui a référencé le bulletin le 27 octobre, et l'entrée OSV porte la même date ; un processus de correctifs piloté par ces alertes n'a donc reçu aucun signal pendant 18 jours après le bulletin et 20 jours après la version corrigée.

Foire aux questions (FAQ)

Mon client MLflow me met-il en danger, ou seulement un serveur auto-hébergé ?

Seulement le côté serveur. La chaîne nécessite les propres endpoints HTTP du serveur de tracking : création d'expérience avec un artifact_location choisi, création de run, téléversement d'artefacts et invocation de scorer. Si vous utilisez MLflow uniquement comme client d'un serveur administré et corrigé par quelqu'un d'autre, votre version du client ne crée pas cette exposition.

Activer l'authentification suffit-il à empêcher l'exploitation ?

Cela arrête la variante non authentifiée et laisse subsister la variante authentifiée. Le bulletin constate que l'endpoint d'invocation des scorers est rattaché à validate_gateway_proxy, qui renvoie true sans contrôle d'autorisation au niveau de l'expérience ou du scorer, si bien que tout principal authentifié capable de créer des expériences, de créer des runs et de téléverser des artefacts peut toujours atteindre le constructeur.

Pourquoi un CVSS de 9,8 alors qu'un système de fichiers en lecture seule bloque l'attaque ?

Le vecteur 9,8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) évalue le déploiement par défaut reproduit par le bulletin : joignable par le réseau, sans authentification, sans interaction utilisateur, et avec un impact total sur la confidentialité, l'intégrité et la disponibilité. La condition du système de fichiers en lecture seule est une mesure de durcissement qui se trouve rompre un maillon de cette chaîne précise, pas une propriété de la configuration par défaut du logiciel.

Les vulnérabilités associées corrigées dans la 3.17.0 justifient-elles à elles seules un correctif ?

La CVE-2026-116690 est une lecture arbitraire de fichiers sur les serveurs non authentifiés (CVSS v3.1 7,5, concerne la 3.10.0 et les versions ultérieures, avant la 3.17.0) : une version de modèle étiquetée comme prompt peut prendre comme source un chemin relatif sans schéma, tel que ../../../tmp, et le serveur sert alors les fichiers de ce chemin. Elle touche des déploiements plus anciens de deux versions mineures que la RCE.

La CVE-2026-116691 (CVSS v3.1 6,5, concerne la 2.19.0 et les versions ultérieures, avant la 3.17.0) enregistre les clés d'API des fournisseurs de LLM dans les spans de traces journalisés lorsque l'autologging de CrewAI est activé, ce qui constitue une exposition de données dans tout déploiement qui partage ses traces.

Une seule mise à niveau vers la 3.17.0 couvre les trois.

Existe-t-il un exploit public ?

Une preuve de concept est jointe au bulletin et elle est volontairement inoffensive : elle écrit un fichier marqueur, le télécharge et vérifie la correspondance. Elle démontre l'exécution sans publier d'arme. Aucune exploitation dans la nature n'est connue et la CVE ne figure pas dans le catalogue KEV, au 28 octobre 2026.

Trouvez les serveurs MLflow exposés avec Ostorlab

Lancez un scan web et API Ostorlab sur l'ensemble de vos environnements : il identifie les endpoints de serveurs de tracking MLflow exposés et les versions qu'ils exécutent, pour que vous puissiez confirmer que chaque déploiement est en 3.17.0 ou ultérieure et qu'aucune instance non authentifiée n'est joignable depuis Internet.

Références

• Bulletin GitHub GHSA-26p8-2jq9-3vq9, CVE-2026-116692, CVSS v3.1 9,8, publié le 9 octobre 2026 et référencé dans la GitHub Advisory Database le 27 octobre 2026, avec l'analyse technique complète et les pièces jointes de la preuve de concept : https://github.com/mlflow/mlflow/security/advisories/GHSA-26p8-2jq9-3vq9 (vérifié le 28 octobre 2026)
• Commit de correctif a732443e, « Match third-party scorer modules exactly instead of by package prefix », 16 septembre 2026 : https://github.com/mlflow/mlflow/commit/a732443e695c3c677680c54320efc394c81654ab (lu en entier le 28 octobre 2026)
• Modification introductrice 02eea260, "Enable third-party scorer registration in OSS MLflow (#22634)", PR #22634: https://github.com/mlflow/mlflow/pull/22634 (consulté le 28 octobre 2026)
• Version MLflow 3.17.0, 7 octobre 2026 : https://github.com/mlflow/mlflow/releases/tag/v3.17.0
• Bulletins associés : GHSA-m65p-9j7q-6w33 (CVE-2026-116690) et GHSA-j7qq-vr8c-xvw3 (CVE-2026-116691) : https://github.com/advisories/GHSA-m65p-9j7q-6w33, https://github.com/advisories/GHSA-j7qq-vr8c-xvw3 (vérifié le 28 octobre 2026)
• Portée des téléchargements, 4 880 597 téléchargements PyPI hebdomadaires : https://pypistats.org/packages/mlflow (vérifié le 28 octobre 2026)
• Catalogue Known Exploited Vulnerabilities de la CISA, confirmant que la CVE-2026-116692 n'y figure pas : https://www.cisa.gov/known-exploited-vulnerabilities-catalog (vérifié le 28 octobre 2026)