MLflow CVE-2026-64849: SSRF que roba credenciales

El 17 de agosto de 2026 se asignó CVE-2026-64849, una vulnerabilidad de server-side request forgery (SSRF) sin autenticación en MLflow, la plataforma de gestión de experimentos de machine learning. En cuestión de horas empezó el escaneo masivo, y dos días después CISA la metió en su catálogo de vulnerabilidades explotadas (KEV). Lo que la hace peligrosa no es novedoso —una SSRF que llega al endpoint de metadata de la nube— sino la velocidad: de PoC a explotación indiscriminada en el mismo día, sobre servidores que muchísimos equipos exponen a internet sin pensarlo dos veces.

CVE-2026-64849 es una SSRF sin autenticación (CVSS 9.3) en el tracking server de MLflow, versiones anteriores a la 3.15.0. Abusa de la función de webhooks del model registry: un atacante hace que el servidor MLflow expuesto emita peticiones HTTP hacia servicios internos, incluido el endpoint link-local de metadata cloud (169.254.169.254), y le devuelva la respuesta. Con eso extrae credenciales temporales, tokens y configuración del entorno. Se corrige actualizando a MLflow 3.15.0.

¿Por qué esta SSRF es tan grave si las SSRF existen hace años?

MLflow CVE-2026-64849: la SSRF que drena credenciales cloud

Porque combina tres cosas que rara vez se juntan: falta de autenticación, un objetivo de altísimo valor y explotación trivial. El endpoint vulnerable es un POST a /api/2.0/mlflow/webhooks/{id}/test que el tracking server por defecto expone sin pedir credenciales. No hace falta una cuenta, ni un token, ni ingeniería social: si el puerto está abierto, el atacante ya puede disparar la petición.

El objetivo es el más jugoso de la nube. El endpoint de metadata (169.254.169.254) entrega credenciales temporales de rol IAM, tokens OAuth y variables de entorno. Con eso el atacante deja de mirar tu MLflow y empieza a moverse por tu cuenta cloud.
La superficie es enorme. MLflow es una de las plataformas de MLOps más usadas del mundo, con decenas de millones de descargas mensuales. Muchos equipos levantan el tracking server para "ver los experimentos" y lo dejan accesible desde afuera.
El score lo dice todo. CVSS 9.3 y un EPSS de 94,4% según la ficha técnica de Miggo — es decir, altísima probabilidad de explotación real, no teórica.

¿Cómo funciona el bypass por redirect (el TOCTOU)?

La clave es que MLflow valida la URL del webhook al registrarla, pero no al seguir un redirect. Es un patrón clásico de time-of-check to time-of-use (TOCTOU): lo que se chequea no es lo que termina usándose.

El flujo del ataque, según el análisis técnico publicado por Miggo, es este:

Registro que pasa la validación. La función _validate_webhook_url() exige que la URL resuelva a una IP pública. El atacante registra un webhook apuntando a su propio servidor, con IP pública legítima. Pasa el chequeo sin problema.
El redirect malicioso. Cuando se dispara el webhook, la librería requests sigue las redirecciones HTTP sin revalidar el destino. El servidor del atacante responde con un 302 apuntando a una IP interna: 169.254.169.254 (metadata) o 127.0.0.1 (loopback).
La fuga de la respuesta. MLflow devuelve el response_status y el response_body de ese servicio interno. El atacante lee, tal cual, lo que contestó el endpoint de metadata.

Este detalle importa: la falla esquiva parches anteriores precisamente por cómo maneja los redirects. No alcanzaba con validar la URL de entrada; había que revalidar en cada salto. "El bug esquiva arreglos previos por cómo maneja las redirecciones web (…) los atacantes abusan de esto para extraer credenciales y secretos desde direcciones IP internas conocidas", explicó Yordan Ganchev, especialista principal de inteligencia de amenazas de watchTowr, en declaraciones recogidas por The Hacker News.

¿Qué pueden robar exactamente los atacantes?

Todo lo que viva detrás de una IP interna alcanzable por HTTP, y en la práctica eso significa las credenciales efímeras de tu instancia. El endpoint link-local 169.254.169.254 es un estándar de facto entre los grandes proveedores cloud, y por diseño entrega:

Credenciales temporales de rol IAM. Las claves de acceso asociadas al rol de la instancia — la llave maestra para actuar como esa máquina dentro de tu cuenta.
Tokens OAuth y de servicio. Credenciales de corta vida que habilitan llamadas a las APIs internas del proveedor.
Configuración del entorno. Variables y metadatos que revelan la arquitectura interna y facilitan el movimiento lateral.

Con estas credenciales el incidente deja de ser "me tocaron el MLflow" y pasa a ser "tienen una identidad válida dentro de mi cuenta cloud". De ahí a exfiltrar datos, montar infraestructura o pivotear a otros servicios hay un paso.

¿Qué implica esto para un proyecto en producción hoy?

Si corrés MLflow expuesto y no estás en 3.15.0, asumí que ya te escanearon. El escaneo fue indiscriminado desde las primeras horas, así que la pregunta no es "¿soy un target?" sino "¿mi instancia estaba abierta cuando pasó la ola?". La respuesta accionable se ordena por prioridad:

Actualizá a MLflow 3.15.0 ya. Es el fix oficial que revalida los destinos tras cada redirect. Es la única solución de raíz.
Sacá el tracking server de internet. MLflow no trae autenticación robusta por defecto: ponelo detrás de VPN, red privada o un reverse proxy con auth. Un tracking server nunca debería ser accesible sin credenciales.
Endurecé el acceso a la metadata. Donde tu proveedor lo permita, exigí la versión de metadata que requiere token (tipo IMDSv2), con lo que un simple GET reflejado ya no alcanza para robar credenciales.
Revisá logs y rotá secretos. Buscá POST a /api/2.0/mlflow/webhooks/ y webhooks registrados que no reconozcas. Si hubo exposición, rotá las credenciales del rol de esa instancia — no confíes en que "quizás no llegaron".

¿Por qué CISA la sumó al KEV en 48 horas?

Porque había explotación activa confirmada, no sospecha teórica. CISA agregó CVE-2026-64849 a su catálogo de vulnerabilidades explotadas el 19 de agosto de 2026 y dio a las agencias federales hasta el 2 de septiembre de 2026 para parchear, bajo su directiva operativa vinculante. Una entrada en el KEV con plazo de dos semanas es la señal más fuerte que da CISA: "esto se está usando contra objetivos reales, arreglalo ya". Aunque el mandato aplica al gobierno de EE. UU., el KEV es la lista de tareas de facto para cualquier equipo de seguridad serio.

Esta SSRF no es un caso aislado: se suma a la tanda de fallas contra infraestructura de datos e IA que venimos cubriendo en la comunidad, como Ray CVE-2025-62593 y el MCPocalipsis de los 30 CVEs en herramientas del ecosistema MCP. El patrón se repite: plataformas pensadas para redes internas terminan expuestas, y el endpoint de metadata cloud es el premio recurrente.

Preguntas frecuentes

¿Qué versiones de MLflow están afectadas por CVE-2026-64849?

Todas las versiones anteriores a MLflow 3.15.0. La corrección llegó en la 3.15.0, que revalida el destino de las peticiones después de seguir cada redirect HTTP.

¿Necesita el atacante credenciales para explotar esta SSRF?

No. La vulnerabilidad es sin autenticación: el endpoint POST /api/2.0/mlflow/webhooks/{id}/test del tracking server queda expuesto sin pedir credenciales. Basta con que la instancia sea alcanzable por red.

¿Cuál es la mitigación si no puedo actualizar de inmediato?

Sacá el tracking server de internet (VPN o red privada), bloqueá el acceso saliente al endpoint de metadata desde el proceso de MLflow y exigí la variante de metadata protegida por token. Son parches temporales: la solución real es actualizar a 3.15.0.

¿Cómo sé si ya me explotaron?

Revisá los logs del tracking server buscando peticiones POST al endpoint de webhooks y webhooks registrados hacia URLs desconocidas. Ante la duda, rotá las credenciales del rol IAM de esa instancia; las credenciales de metadata son temporales pero suficientes para el abuso.

¿Por qué fallaron los parches anteriores?

Porque validaban la URL del webhook al registrarla, pero la librería HTTP seguía los redirects sin volver a chequear el destino (un TOCTOU). El atacante registra una URL pública válida y luego la redirige a una IP interna. La 3.15.0 cierra ese hueco revalidando en cada salto.

Fuentes: BleepingComputer — CISA warns of hackers exploiting critical MLflow vulnerability · The Hacker News — Attackers Exploit MLflow SSRF Flaw to Steal Cloud Credentials · Miggo — CVE-2026-64849: MLflow Webhook SSRF via Redirect · SecurityWeek — MLflow Vulnerability Exploited for Cloud Credential Theft