MLflow bajo ataque: una SSRF crítica expone credenciales cloud y servicios internos

CISA incorpora CVE-2026-64849 al catálogo KEV

CISA ha alertado sobre la explotación activa de CVE-2026-64849, una vulnerabilidad crítica en MLflow, una plataforma open source utilizada para desarrollar, evaluar y supervisar modelos de machine learning, aplicaciones de inteligencia artificial y Large Language Models.

El fallo es una Server-Side Request Forgery (SSRF) clasificada como CWE-918. Un atacante remoto no autenticado puede inducir al servidor MLflow a realizar solicitudes contra recursos internos que no son accesibles directamente desde Internet.

CVE-2026-64849 se incorporó al catálogo CISA Known Exploited Vulnerabilities (KEV) el 19 de agosto de 2026. Para las agencias civiles federales estadounidenses, la fecha límite para aplicar la remediación es el 2 de septiembre de 2026.

La vulnerabilidad tiene una puntuación CVSS 3.1 de 9.3, con el siguiente vector:

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

El valor refleja que no se requiere autenticación, que el ataque puede ejecutarse de forma remota y que el impacto sobre la confidencialidad es elevado. CISA también indica que la explotación está activa, puede automatizarse y tiene un impacto técnico total.

Según la información disponible, los atacantes comenzaron a buscar sistemas MLflow vulnerables pocas horas después de la asignación del CVE. CISA no ha publicado más detalles sobre los ataques observados.

Qué instalaciones de MLflow están expuestas

El riesgo afecta principalmente a los tracking servers iniciados con el comando:

mlflow server

y configurados sin autenticación, utilizando la base de datos SQLite predeterminada:

sqlite:///mlflow.db

Esta configuración es relevante porque los webhooks del model registry requieren un almacén SQL. Por tanto, el servidor predeterminado cumple los requisitos para exponer las API afectadas.

Una instalación está especialmente expuesta cuando el tracking server:

• es accesible desde Internet;
• no exige autenticación;
• tiene acceso a redes internas o servicios cloud;
• puede comunicarse con los endpoints de metadata de las instancias;
• utiliza las funciones de webhook del model registry.

MLflow registra más de 30 millones de descargas mensuales y es utilizado por miles de organizaciones. La vulnerabilidad puede afectar a entornos de desarrollo, plataformas MLOps e infraestructuras cloud que alojan modelos o pipelines de IA.

La información sobre las versiones afectadas no coincide plenamente entre los distintos avisos. NVD considera vulnerables todas las versiones anteriores a la 3.15.0. El GitHub Security Advisory señala, en cambio, las versiones hasta la 3.13.0 incluida, aunque describe la corrección en la release 3.15.0 y en el parche #24258.

El exploit se confirmó en MLflow 3.13.0 con la base de datos SQLite predeterminada. Como medida de precaución, todas las instalaciones anteriores a la 3.15.0 deben considerarse vulnerables.

Cómo funciona el bypass de SSRF

La vía principal utiliza el endpoint no autenticado:

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

Este endpoint sirve para probar un webhook y devuelve al solicitante el estado de la respuesta recibida del servicio remoto, junto con su contenido.

MLflow realiza una comprobación inicial de la URL del webhook. Verifica el esquema, resuelve el nombre de host y rechaza direcciones no públicas, incluidas las privadas, de loopback, link-local y destinadas a servicios de metadata. En condiciones normales, solo se permite el esquema https.

Sin embargo, la comprobación no vincula la dirección IP verificada con la conexión posterior. El componente de entrega:

• sigue automáticamente las redirecciones HTTP;
• no desactiva allow_redirects;
• no vuelve a validar la URL incluida en la cabecera Location;
• puede realizar una nueva resolución DNS al establecer la conexión.

De este modo, el atacante puede registrar un webhook dirigido a un host HTTPS público que parezca legítimo. Tras superar la validación, su servidor responde con una redirección 302 hacia un recurso interno, por ejemplo:

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

El servidor MLflow sigue la redirección y ejecuta la solicitud desde su propio entorno de red. A continuación, el endpoint /test devuelve al atacante el código HTTP y el cuerpo de la respuesta upstream.

La segunda vía de bypass aprovecha el DNS rebinding. La resolución DNS realizada durante la comprobación inicial puede devolver una dirección pública, mientras que la efectuada por la biblioteca HTTP durante la conexión puede apuntar a una dirección interna. Como la IP aprobada no queda fijada durante la validación, la solicitud puede alcanzar un destino diferente.

La vulnerabilidad permite contactar con:

• endpoints AWS IMDS y otros servicios de metadata cloud;
• servicios administrativos internos;
• direcciones de loopback;
• puertos y hosts pertenecientes a redes privadas;
• sistemas que no están expuestos fuera del perímetro de la red.

El acceso a los servicios de metadata cloud puede exponer credenciales temporales de AWS IAM, tokens y otros secretos. La SSRF también puede utilizarse para realizar escaneos de puertos y descubrir hosts internos.

El aviso distingue entre una SSRF “blind”, asociada al flujo normal de entrega de eventos, y una SSRF con lectura de la respuesta, posible mediante el endpoint /test.

El PoC demuestra la recuperación de datos internos

La demostración publicada consta de tres pasos.

Primero se intenta registrar un webhook dirigido a una dirección local, como 127.0.0.1. La comprobación responde con un error HTTP 400 porque el esquema o la dirección no están permitidos.

A continuación, se registra un webhook hacia un host HTTPS público controlado por el atacante. La URL supera la validación y es aceptada.

Por último, el servidor del atacante responde con una redirección hacia un servicio interno. El atacante llama entonces al endpoint /test, que puede devolver una estructura similar a esta:

{
  "result": {
    "success": true,
    "response_status": 200,
    "response_body": "<contenido del servicio interno>"
  }
}

En una prueba local, el investigador introdujo manualmente en el servicio interno valores como:

INTERNAL_SECRET=mlflow_ssrf_proof_7f3a91
role=admin

No eran credenciales cloud reales. Sin embargo, la prueba demuestra que el contenido de una respuesta interna puede transferirse al atacante.

El ataque no requiere autenticación y se ejecuta desde el servidor MLflow, no desde el navegador ni desde el equipo de la víctima. Además, los valores de los eventos deben utilizar nombres de proto en mayúsculas, como REGISTERED_MODEL y CREATED.

Parche, mitigaciones y respuesta

La corrección está disponible en MLflow 3.15.0 y está asociada a la pull request #24258 y al commit:

ba949522477cbd5915aa55d29b0cfad7d5ddf939

El proyecto incorporó SSRFProtectedHTTPAdapter, que comprueba la dirección IP del socket remoto justo después de establecer la conexión y antes del intercambio TLS o HTTP. La comprobación también se aplica a las redirecciones, lo que impide reutilizar el bypass mediante respuestas 302, 307 y 308.

La medida también resuelve el problema del DNS rebinding: se verifica la IP a la que se conecta realmente el sistema, en lugar de confiar únicamente en la resolución inicial.

Los administradores deberían:

1. actualizar MLflow a la versión 3.15.0 o posterior;
2. dar prioridad a los tracking servers expuestos a Internet y sin autenticación;
3. habilitar una autenticación efectiva y comprobar la autorización de los webhooks;
4. limitar las conexiones salientes del proceso MLflow;
5. bloquear el acceso a 169.254.169.254, redes privadas, loopback y servicios administrativos innecesarios;
6. revisar proxies, firewalls y filtros de salida para impedir solicitudes hacia destinos internos.

Los registros deben analizarse en busca de solicitudes dirigidas a:

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

También son sospechosos el registro de webhooks hacia hosts externos inesperados, las redirecciones hacia direcciones privadas y los accesos a 169.254.169.254.

Si existe la posibilidad de que la instancia haya sido comprometida, debe comprobarse la posible exposición de credenciales cloud, tokens y secretos. Las credenciales de AWS IAM potencialmente comprometidas deben revocarse o rotarse, junto con un análisis de los usos posteriores.

La vulnerabilidad fue comunicada de forma privada el 12 de junio de 2026 por @freeman-bb. Una revisión independiente de @AUTHENSOR se hizo pública el 26 de junio de 2026 en el issue #24179.

CVE-2026-64849 no debe confundirse con CVE-2025-14279, que afecta a una vulnerabilidad CSRF con DNS rebinding y pertenece a la categoría CWE-352, no a una SSRF server-side de este tipo.