Actores de amenazas están explotando activamente una vulnerabilidad crítica de falsificación de solicitudes del lado del servidor (SSRF) no autenticada en MLflow, una plataforma de código abierto utilizada para el aprendizaje automático y la ingeniería de datos. El fallo, identificado como CVE-2026-64849, posee una puntuación crítica de 9.3 en CVSS 3.1 y afecta a todas las versiones de MLflow anteriores a la actualización más reciente.

Actores de amenazas están explotando activamente una vulnerabilidad crítica de falsificación de solicitud del lado del servidor (SSRF) no autenticada en MLflow, la popular plataforma de código abierto ampliamente utilizada por equipos de ingeniería de datos y aprendizaje automático para rastrear experimentos, empaquetar código y desplegar modelos.

Identificada como CVE-2026-64849 con una puntuación crítica CVSS 3.1 de 9.3, el fallo afecta a todas las versiones de MLflow anteriores a la 3.15.0.

El monitoreo de amenazas realizado por watchTowr Intel a través de su red global de sensores honeypot Attacker Eye identificó adversarios dirigiéndose a instancias de MLflow expuestas a internet a las pocas horas de la divulgación pública para recolectar credenciales de la nube y tokens de despliegue sensibles.

Vulnerabilidad Crítica de SSRF en MLflow Explotada en Entornos Reales

Un Servidor de Rastreo de MLflow predeterminado inicializado vía mlflow server se ejecuta sin autenticación obligatoria y depende de un backend de SQLite local, exponiendo la API de webhooks del registro de modelos al tráfico de red no confiable.

La ruta principal de la vulnerabilidad reside en una solicitud POST no autenticada a /api/2.0/mlflow/webhooks/{id}/test.

En lugar de simplemente activar el webhook designado, el endpoint refleja el código de estado HTTP ascendente completo y el cuerpo de la respuesta al solicitante, convirtiendo una falsificación de solicitud ciega estándar en una primitiva de lectura completa de alto impacto.

Aunque MLflow introdujo previamente el asistente _validate_webhook_url() en la versión 3.10.0 para rechazar direcciones de metadatos de la nube y privadas, la validación solo evalúa el destino inicial.

El manejador de entrega subyacente en mlflow/webhooks/delivery.py continúa siguiendo las redirecciones HTTP sin volver a validar la dirección secundaria. Un atacante puede configurar un endpoint público que pase las comprobaciones iniciales y devuelva una redirección HTTP 302 apuntando hacia servicios de metadatos de la nube locales o interfaces de bucle interno (loopback).

Además, debido a que el nombre de host se resuelve nuevamente tras la verificación inicial de la lista de permitidos, la interfaz sigue siendo susceptible a ataques de DNS-rebinding. Fallos arquitectónicos similares han aparecido en otras vulnerabilidades de bypass de SSRF en diversos marcos de aprendizaje automático.

Según watchTowr Cyber Intelligence, los escáneres automatizados comenzaron a atacar endpoints de MLflow alojados en la nube casi inmediatamente después de que la vulnerabilidad recibiera su identificador oficial.

Una vulnerabilidad de SSRF no autenticada en MLflow, CVE-2026-64849, ya está siendo explotada en entornos reales.

A las pocas horas de la asignación del CVE, watchTowr Intel a través de Attacker Eye, nuestra red global de honeypots, observó a atacantes dirigiéndose a sistemas MLflow alojados en la nube en un intento de…

— watchTowr (@watchtowrcyber) Agosto 18, 2026

En los principales proveedores de la nube, incluidos Amazon Web Services, Microsoft Azure y Google Cloud Platform, la respuesta reflejada permite a los atacantes extraer credenciales temporales de roles IAM, tokens OAuth y configuraciones de entorno desde la dirección de metadatos local en http://169.254.169.254/.

Más allá de los metadatos del proveedor de la nube, el exploit puede consultar microservicios internos y consolas administrativas de bucle interno que confían implícitamente en el entorno del host.

La velocidad de estas intrusiones refleja tendencias más amplias donde los escáneres automatizados convierten rápidamente en armas las vulnerabilidades de software zero-click contra infraestructuras empresariales expuestas.

Los mantenedores han resuelto la exposición a la redirección y al DNS-rebinding en MLflow 3.15.0 a través de la solicitud de extracción (pull request) 24258. Las organizaciones que operen Servidores de Rastreo compartidos o expuestos a internet deben actualizar inmediatamente a la versión 3.15.0 o posterior.

Debido a que aplicar parches no revoca las credenciales que pueden haber sido ya exfiltradas, tu equipo de seguridad debe auditar los registros de acceso para solicitudes dirigidas a /webhooks/*/test, rotar todas las claves IAM de la nube y secretos de API asignados a las instancias host, y aplicar un filtrado de salida de red para restringir la comunicación no autorizada con direcciones de metadatos locales.

Ejecutar una gestión de parches de emergencia rigurosa y colocar MLflow detrás de proxies conscientes de la identidad garantiza que tus portales de rastreo internos permanezcan aislados de las redes de escaneo público.

Fuentes:
https://cybersecuritynews.com/mlflow-ssrf-vulnerability/