RCE sin autenticación en los servidores de tracking de MLflow (CVE-2026-116692)

Resumen (TL;DR)

• CVE-2026-116692 es una ejecución remota de código (RCE) en el propio servidor de tracking de machine learning de MLflow: cualquier cliente HTTP que pueda alcanzar el servidor puede subir un módulo Python y conseguir que el servidor lo importe y lo ejecute, sin credenciales en un despliegue predeterminado. El aviso de seguridad de GitHub le asigna severidad Critical, CVSS v3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
• Las versiones 3.12.0 a 3.16.x de MLflow están afectadas, al igual que la release candidate 3.12.0rc0. La primera versión corregida es la 3.17.0, publicada el 7 de octubre de 2026.
• El fallo es una cadena: la deserialización de scorers de terceros del servidor acepta cualquier ruta de módulo que empiece por un prefijo de paquete incluido en la lista de permitidos, y los propios endpoints de experimentos y artefactos del servidor permiten a un cliente hacer que la ubicación de artefactos de un experimento apunte a uno de esos paquetes y subir un archivo Python debajo de él. Los scorers son las funciones de evaluación de MLflow para las salidas de aplicaciones LLM y de agentes, y los scorers de terceros envuelven métricas de bibliotecas como Ragas, DeepEval, TruLens y Phoenix. En la imagen oficial de MLflow v3.14.0 el proceso se ejecuta como root, por lo que el código se ejecuta como root.
• No se conoce explotación activa y la CVE no figura en el catálogo KEV de CISA. El aviso de seguridad incluye una prueba de concepto inofensiva.
• Actualice a la 3.17.0 y vuelva a crear los contenedores del servidor. Si no puede actualizar hoy, restrinja quién puede alcanzar el servidor: la autenticación básica no detiene a un usuario autenticado que pueda crear experimentos y subir artefactos.

¿Estoy afectado?

Está afectado si ejecuta un servidor de tracking de MLflow desde la 3.12.0 hasta la 3.17.0 sin incluirla, accesible por HTTP para clientes que no deberían poder crear experimentos ni subir artefactos, y cuyo proceso puede escribir dentro de alguno de sus paquetes de scorers instalados. Deben cumplirse estas tres condiciones:

• Ejecuta un servidor de tracking de MLflow en la versión 3.12.0 (incluidas sus release candidates) o posterior, por debajo de la 3.17.0. La funcionalidad de scorers de terceros que contiene el fallo aparece por primera vez en la 3.12.0.
• Los endpoints HTTP del servidor (experimento, run, subida de artefactos y la ruta de invocación de scorers) son accesibles para clientes que no deberían poder crear experimentos ni subir artefactos. La autenticación está desactivada por defecto, y mlflow server escucha en 127.0.0.1 salvo que se inicie con otro --host, como 0.0.0.0; en cuanto escucha más allá de loopback, o un proxy le reenvía peticiones, expone esos endpoints a cualquiera que pueda llegar a su puerto. Con la autenticación básica activada, la exposición se reduce a cualquier principal autenticado que pueda crear experimentos y runs, y subir artefactos.
• El proceso del servidor puede escribir debajo de uno de sus paquetes de scorers instalados. El aviso indica que esto ocurre en la imagen oficial de MLflow y en los entornos virtuales instalados y ejecutados por el mismo usuario del sistema operativo; un sistema de archivos de contenedor de solo lectura o un directorio de paquetes de scorers en el que el proceso del servidor no puede escribir bloquea esta cadena de colocación concreta.

Como referencia de escala, PyPI registró 4,880,597 descargas de mlflow en la semana anterior al 28 de octubre de 2026; esa cifra cuenta todas las descargas, no solo los servidores de tracking.

Consulte primero el servidor en ejecución y compare su versión con el paquete instalado en ese despliegue. Los metadatos del paquete no demuestran que un proceso se haya reiniciado tras una actualización:

# 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"'

¿Cómo se corrige?

Actualice el paquete del servidor a la 3.17.0 y vuelva a crear los contenedores del servidor, para que se reemplace el proceso en ejecución y no solo la imagen en disco:

pip install -U "mlflow>=3.17.0"

pip install -U solo reemplaza los archivos en disco: un proceso del servidor iniciado antes de la actualización conserva el código vulnerable en memoria hasta que se reinicia. Reinicie el proceso del servidor (por ejemplo con systemctl restart sobre su unidad, o el equivalente de su gestor de procesos) y después pida su versión al servidor en ejecución a través de su endpoint /version. Debe devolver 3.17.0 o una versión posterior:

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

En un servidor en contenedores, cambie el tag de la imagen, descárguela y vuelva a crear el contenedor; un contenedor antiguo que solo se reinicia conserva el código antiguo. Después, ejecute la comprobación de versión con docker exec indicada arriba sobre el nuevo contenedor: debe mostrar 3.17.0 o una versión posterior.

La misma versión corrige además dos vulnerabilidades relacionadas:

• CVE-2026-116690: lectura arbitraria de archivos en servidores sin autenticación, a través de la ruta de origen de una versión de modelo etiquetada como prompt (CVSS v3.1 7.5, afecta de la 3.10.0 a la 3.16.x); la sección FAQ más abajo explica el mecanismo.
• CVE-2026-116691: el autologging de CrewAI registra las claves de API de los proveedores de LLM en los spans de las trazas registradas (CVSS v3.1 6.5, afecta de la 2.19.0 a la 3.16.x).

Si no puede actualizar hoy, tres mitigaciones reducen la ventana de exposición, cada una con sus límites:

• Restringir la accesibilidad de red del servidor de tracking (escucha en loopback, VPN, un ingress con autenticación o una lista de IP permitidas). Límite: reduce la superficie de ataque pero no corrige nada; cualquier cliente que siga dentro del perímetro puede explotar el endpoint.
• Activar la autenticación básica de MLflow. Límite: el endpoint de invocación de scorers no está protegido por una comprobación de permisos específica del recurso, por lo que un principal autenticado con acceso a experimentos, runs y artefactos sigue siendo una amenaza.
• Ejecutar el servidor con un sistema de archivos de contenedor de solo lectura o con directorios de paquetes de scorers en los que el proceso del servidor no puede escribir. Límite: bloquea esta cadena de colocación de archivos concreta; no corrige el comportamiento de deserialización subyacente.

¿Cuál es la causa raíz?

El deserializador de scorers trata un prefijo de cadena como una frontera de procedencia y luego importa cualquier módulo que indique la solicitud, mientras que los propios endpoints de artefactos del servidor permiten a un cliente colocar un módulo dentro de esa frontera. MLflow 3.12.0 introdujo el registro y la deserialización de scorers de terceros en la versión de código abierto de MLflow (commit 02eea260, pull request #22634). En el commit de la versión v3.14.0, mlflow/genai/scorers/scorer_utils.py define las raíces permitidas:

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

En mlflow/genai/scorers/base.py, el deserializador acepta una raíz exacta o cualquier descendiente y después realiza tres operaciones con valores controlados por la solicitud:

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 prefijo de nombre de paquete no es una frontera de procedencia. Si el proceso del servidor puede escribir debajo de un paquete permitido, un descendiente creado por el atacante supera la comprobación de cadena y se convierte en código importable.

La otra mitad de la cadena es la estructura de los artefactos. El endpoint de creación de experimentos acepta un artifact_location, y MLflow deriva el directorio de artefactos de cada run como <artifact_location>/<run_id>/artifacts/. En la imagen oficial de MLflow v3.14.0, un cliente puede fijar la ubicación de artefactos de un experimento en file:///usr/local/lib/python3.10/site-packages/mlflow/genai/scorers/trulens. A continuación, el cliente sube un módulo a través del endpoint de artefactos de run, y el archivo queda en la ruta de importación mlflow.genai.scorers.trulens.<run_id>.artifacts.<module>, dentro del prefijo permitido.

Por último, en mlflow/server/handlers.py, _invoke_scorer_handler() deserializa y construye el scorer antes de validar o resolver los identificadores de traza proporcionados, de modo que el constructor controlado por el atacante se ejecuta primero. Con la autenticación desactivada, como en la configuración predeterminada reproducida, no se necesitan credenciales.

¿Cómo se explota?

Un cliente que puede llegar al servidor usa los propios endpoints de experimentos, runs y artefactos de MLflow para escribir un módulo de Python dentro de un paquete de scorers permitido, y después hace que la ruta de invocación de scorers importe ese módulo y construya una clase a partir de él. La prueba de concepto incluida en el aviso encadena esos endpoints, de principio a fin:

1. Crear un experimento cuyo artifact_location apunte a un paquete de scorers permitido y con permisos de escritura, por ejemplo file:///usr/local/lib/python3.10/site-packages/mlflow/genai/scorers/trulens en la imagen oficial.
2. Crear un run, lo que hace que MLflow reserve <artifact_location>/<run_id>/artifacts/.
3. Subir un módulo Python, audit_<token>.py, a ese directorio de artefactos del run a través del endpoint de subida de artefactos de run.
4. Enviar un scorer de terceros serializado cuya ruta module se resuelva en el archivo subido: mlflow.genai.scorers.trulens.<run_id>.artifacts.audit_<token>.
5. Desencadenar la importación y la construcción de la clase mediante POST /ajax-api/3.0/mlflow/scorer/invoke.

El constructor controlado por el atacante se ejecuta entonces en el proceso del servidor MLflow. En la prueba de concepto (PoC), el constructor escribe un archivo marcador aleatorio junto a su propio artefacto subido; después, la PoC descarga ese archivo a través del endpoint de artefactos de run y comprueba que coincide exactamente, lo que demuestra la ejecución. El fallo posterior en el procesamiento de trazas y el error HTTP 500 se producen cuando el constructor ya se ha ejecutado, así que el 500 no descarta la explotación.

La reproducción remota del aviso ejecutó la misma cadena contra un host desechable en la nube con la imagen oficial v3.14.0, fijada por el digest de su manifiesto, con el proceso ejecutándose como uid 0 y el archivo marcador indicando whoami: root.

¿Qué puede hacer un atacante?

En el despliegue estándar sin autenticación reproducido, cualquier cliente de red que alcance el servidor de tracking ejecuta código Python como el proceso de MLflow, sin credenciales y sin interacción del usuario. El aviso detalla el alcance del daño: impacto total en la confidencialidad, la integridad y la disponibilidad de todos los datos, credenciales, accesos de red y ubicaciones del sistema de archivos a los que tiene acceso el proceso del servidor. La imagen oficial ejecuta el proceso como root, lo que aumenta el impacto a nivel de contenedor; el impacto en el host sigue dependiendo de la configuración del runtime de contenedores, las rutas montadas, las capabilities concedidas y la exposición de sockets.

A fecha de 28 de octubre de 2026 no hay ningún exploit público listo para usar.

¿Por qué funciona la corrección?

La corrección, el commit a732443e («Match third-party scorer modules exactly instead of by package prefix», pull request #25906, fusionado el 16 de septiembre de 2026), sustituye la coincidencia por prefijo por una coincidencia exacta:

-            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 propia lista de permitidos se amplió para nombrar literalmente cada módulo de scorer concreto, por ejemplo mlflow.genai.scorers.ragas.scorers.rag_metrics, de modo que las importaciones legítimas siguen funcionando. Un descendiente colocado por el cliente, como mlflow.genai.scorers.trulens.<run_id>.artifacts.audit_<token>, ya no coincide con ninguna entrada de la lista, así que la cadena de colocación de artefactos queda rota. Tres controles adicionales bloquean las demás rutas de importación a las que podría llegar una solicitud:

• metric_name debe ser un identificador Python simple, porque los wrappers de scorers de Ragas y DeepEval de MLflow resuelven los nombres de métricas desconocidos insertándolos en una ruta de importación como ragas.metrics.collections.<metric_name> o deepeval.metrics.<metric_name>.
• kwargs no puede sobrescribir el metric_name validado.
• Tras la importación, la clase obtenida debe ser una subclase de Scorer antes de instanciarse.

En conjunto, estos cambios hacen que el deserializador importe solo los módulos que distribuye el propio MLflow, que es lo que pretendía el diseño original.

¿Cómo compruebo si he sido comprometido?

El material publicado describe la prueba de concepto, no indicadores de atacantes, por lo que no existe ninguna lista pública de indicadores. A partir de la mecánica descrita en el propio aviso, un despliegue afectado puede buscar los rastros que deja la cadena:

• Busque archivos .py dentro de los paquetes de scorers instalados que sean más recientes que el __init__.py de MLflow. Ejecute los comandos con el intérprete del servidor, para que $MLFLOW_ROOT sea la ruta desde la que el servidor importa sus módulos:

# 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"

• Audite el tracking store en busca de experimentos cuyo artifact_location sea una ruta file:// dentro de la instalación de Python, en particular bajo site-packages/mlflow/genai/scorers/; la prueba de concepto usa exactamente este patrón. En un backend store SQL, consulte la tabla experiments (el ejemplo de SQLite siguiente funciona igual con psql o mysql); en un store mlruns basado en archivos, el meta.yaml de cada experimento contiene su 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

• Busque en los registros de acceso del servidor solicitudes POST a /ajax-api/3.0/mlflow/scorer/invoke cuyo contenido incluya third_party_scorer_data con una ruta module que contenga un segmento .artifacts.. La cadena siempre produce una ruta con la forma mlflow.genai.scorers.<package>.<run_id>.artifacts.<module>, con el identificador de run de 32 caracteres hexadecimales justo antes de .artifacts., y ningún módulo que distribuye MLflow contiene ese segmento.
• Busque en los registros de acceso del servidor subidas de archivos .py. La ruta de subida de artefactos de run de MLflow, POST /ajax-api/2.0/mlflow/upload-artifact, recibe el nombre del archivo de destino en su parámetro de consulta path, así que esta comprobación sigue funcionando aunque el archivo subido se haya borrado:

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

Una revisión de registros sin hallazgos ofrece una garantía débil, en particular si el servidor funcionó con la autenticación desactivada en una red abierta durante cualquier periodo con una versión afectada. Cada paso pasa por los propios endpoints de experimentos, runs, artefactos y scorers de MLflow, por lo que ninguna solicitud apunta a un endpoint inusual, y solo detalles como los anteriores distinguen estas solicitudes de un uso legítimo. Los rastros que persisten son el registro del experimento con su artifact_location en file:// y el directorio del run que contiene el módulo subido. En la prueba de concepto, además, hay un archivo marcador junto al módulo. El código que se ejecuta como el proceso del servidor puede borrar todos estos rastros.

Si encuentra alguno de estos rastros, trate el servidor como comprometido en lugar de limitarse a actualizarlo en su sitio. El aviso incluye en el alcance todos los datos, credenciales, accesos de red y ubicaciones del sistema de archivos disponibles para el proceso del servidor, así que aísle el servidor, rote todas las credenciales que ese proceso podía leer y vuelva a crearlo a partir de una imagen limpia de la versión 3.17.0 o posterior.

Cronología

• 2026-07-12: la salida depurada de la reproducción remota del aviso registra esta fecha como hora del servidor, y el aviso indica que no se había identificado ninguna versión corregida a esa fecha (aviso de GitHub, transcripción de la prueba de concepto).
• 2026-09-16: el commit de corrección a732443e se fusiona en master mediante la pull request #25906: coincidencia exacta de módulos más los controles de identificador, kwargs y subclase (commit de GitHub).
• 2026-10-07: se publica MLflow 3.17.0 con la corrección (releases de GitHub).
• 2026-10-09: MLflow publica el aviso de seguridad del repositorio GHSA-26p8-2jq9-3vq9 (08:20 UTC), que califica el problema como Critical, CVSS v3.1 9.8 (aviso de seguridad de GitHub).
• 2026-10-27: la GitHub Advisory Database incluye GHSA-26p8-2jq9-3vq9 (21:26 UTC).
• 2026-10-28: este artículo.

La propia corrección llegó más de dos meses después de la reproducción de julio. Para un servidor afectado, expuesto desde julio y no actualizado el 7 de octubre, las únicas señales públicas antes del aviso del 9 de octubre fueron el commit de corrección del 16 de septiembre y una entrada de una línea en las notas de la versión 3.17.0, ambos con el título «Match third-party scorer modules exactly instead of by package prefix (GHSA-26p8-2jq9-3vq9)». Los escáneres de dependencias tardaron todavía más en avisar: las alertas de Dependabot se basan en la GitHub Advisory Database, que incluyó el aviso el 27 de octubre, y la entrada de OSV tiene la misma fecha, así que un proceso de parches guiado por esas alertas no recibió ninguna señal durante 18 días después del aviso y 20 días después de la versión corregida.

Preguntas frecuentes (FAQ)

¿Mi cliente de MLflow me pone en riesgo, o solo un servidor autoalojado?

Solo el lado del servidor. La cadena necesita los propios endpoints HTTP del servidor de tracking: creación de experimentos con un artifact_location elegido, creación de runs, subida de artefactos e invocación de scorers. Si solo usa MLflow como cliente de un servidor que otra persona administra y parchea, su versión del cliente no genera esta exposición.

¿Activar la autenticación lo detiene?

Detiene la variante sin autenticación y deja abierta la autenticada. El aviso constata que el endpoint de invocación de scorers está asignado a validate_gateway_proxy, que devuelve true sin comprobar permisos a nivel de experimento o de scorer, por lo que cualquier principal autenticado que pueda crear experimentos, crear runs y subir artefactos puede seguir llegando al constructor.

¿Por qué la puntuación CVSS es 9.8 si un sistema de archivos de solo lectura lo bloquea?

El vector 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) puntúa el despliegue predeterminado que reprodujo el aviso: accesible por red, sin autenticación, sin interacción del usuario y con impacto total en la confidencialidad, la integridad y la disponibilidad. La condición del sistema de archivos de solo lectura es una medida de bastionado que rompe un eslabón de esta cadena concreta, no una propiedad de la configuración predeterminada del software.

¿Merecen un parche por sí solas las vulnerabilidades relacionadas corregidas en la 3.17.0?

CVE-2026-116690 es una lectura arbitraria de archivos en servidores sin autenticación (CVSS v3.1 7.5, afecta a la 3.10.0 y posteriores, antes de la 3.17.0): una versión de modelo etiquetada como prompt puede tomar como origen una ruta relativa sin esquema, como ../../../tmp, y el servidor sirve entonces archivos desde esa ruta. Alcanza a despliegues dos versiones menores más antiguos que la RCE.

CVE-2026-116691 (CVSS v3.1 6.5, afecta a la 2.19.0 y posteriores, antes de la 3.17.0) registra las claves de API de los proveedores de LLM en los spans de las trazas registradas cuando el autologging de CrewAI está activado, lo que supone una exposición de datos en cualquier despliegue que comparta trazas.

Una sola actualización a la 3.17.0 cubre las tres.

¿Hay un exploit público?

El aviso incluye una prueba de concepto que es deliberadamente inofensiva: escribe un archivo marcador, lo descarga y comprueba la coincidencia. Demuestra la ejecución sin publicar un arma. No se conoce explotación activa y la CVE no figura en el catálogo KEV, a fecha de 28 de octubre de 2026.

Encuentre servidores MLflow expuestos con Ostorlab

Ejecute un escaneo web y de API de Ostorlab en todos sus entornos: identifica los endpoints de servidores de tracking de MLflow expuestos y las versiones que ejecutan, para que pueda confirmar que cada despliegue usa la 3.17.0 o posterior y que no hay ninguna instancia sin autenticación accesible desde internet.

Referencias

• Aviso de GitHub GHSA-26p8-2jq9-3vq9, CVE-2026-116692, CVSS v3.1 9.8, publicado el 9 de octubre de 2026 e incluido en la GitHub Advisory Database el 27 de octubre de 2026, con el análisis técnico completo y los adjuntos de la prueba de concepto: https://github.com/mlflow/mlflow/security/advisories/GHSA-26p8-2jq9-3vq9 (consultado el 28 de octubre de 2026)
• Commit de corrección a732443e, «Match third-party scorer modules exactly instead of by package prefix», 16 de septiembre de 2026: https://github.com/mlflow/mlflow/commit/a732443e695c3c677680c54320efc394c81654ab (leído íntegramente el 28 de octubre de 2026)
• Cambio que introdujo la funcionalidad 02eea260, "Enable third-party scorer registration in OSS MLflow (#22634)", PR #22634: https://github.com/mlflow/mlflow/pull/22634 (consultado el 28 de octubre de 2026)
• Versión MLflow 3.17.0, 7 de octubre de 2026: https://github.com/mlflow/mlflow/releases/tag/v3.17.0
• Avisos relacionados: GHSA-m65p-9j7q-6w33 (CVE-2026-116690) y GHSA-j7qq-vr8c-xvw3 (CVE-2026-116691): https://github.com/advisories/GHSA-m65p-9j7q-6w33, https://github.com/advisories/GHSA-j7qq-vr8c-xvw3 (consultado el 28 de octubre de 2026)
• Alcance de descargas, 4,880,597 descargas semanales en PyPI: https://pypistats.org/packages/mlflow (consultado el 28 de octubre de 2026)
• Catálogo Known Exploited Vulnerabilities de CISA, que confirma que CVE-2026-116692 no figura en él: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultado el 28 de octubre de 2026)