La vulnerabilidad en MLflow identificada como CVE-2026-64849 ya está siendo explotada en ataques reales. Según los reportes de seguridad, los actores maliciosos aprovechan un fallo para forzar peticiones HTTP desde el lado del servidor, con el objetivo de acceder a recursos internos y, en particular, a información sensible de la nube.
MLflow es una plataforma open source de ingeniería de IA que ayuda a gestionar el ciclo de vida completo del machine learning y a desplegar modelos y agentes en entornos de producción. Aunque el proyecto cuenta con una adopción amplia (decenas de miles de estrellas en GitHub y más de 60 millones de descargas mensuales), el uso extendido también vuelve crítica la rápida corrección de vulnerabilidades.
Qué es la vulnerabilidad en MLflow y por qué importa
El problema está catalogado como CVE-2026-64849 y tiene una puntuación CVSS de 9.3, lo que refleja un riesgo alto. El defecto se describe como una SSRF no autenticada (Server-Side Request Forgery) a nivel de servidor.
En términos prácticos, una SSRF permite que un atacante haga que el sistema vulnerable realice solicitudes HTTP hacia destinos que normalmente no serían accesibles directamente desde fuera. Cuando esos destinos incluyen servicios internos o endpoints relevantes, el impacto puede ir más allá de la lectura de datos y terminar en el robo de secretos.
Cómo funciona el ataque: SSRF y endpoints sin autenticación
De acuerdo con el aviso técnico del proyecto, la raíz del incidente se relaciona con la configuración por defecto del Tracking Server de MLflow (mlflow server). El servidor expone un componente vinculado a las webhooks del model-registry sin un mecanismo de autenticación.
Un endpoint expuesto puede devolver al solicitante el estado y el contenido de la respuesta “aguas arriba” (es decir, la respuesta del destino al que se hace la petición). Esto facilita que el atacante obtenga información que, de otro modo, no debería ser accesible.
Además, el reporte indica que una protección contra SSRF agregada en la versión 3.10.0 pudo ser superada. Esa combinación —falta de autenticación y posibilidad de evadir la mitigación— explica por qué el fallo se convirtió en un vector útil para objetivos reales.
El objetivo final: servicios de metadatos y exfiltración
Un aviso de WatchTowr señala que los atacantes están aprovechando el problema para llegar directamente a servicios de metadatos de la nube y extraer credenciales y secretos.
Los servicios de metadatos suelen contener información que las instancias usan para autenticar o autorizar acceso a otros recursos. Si un atacante consigue que el servidor vulnerable consulte esos servicios, puede obtener datos que luego permiten escalar el impacto: desde acceso indebido a almacenamiento o bases de datos, hasta control más amplio del entorno.
Desde cuándo se explota y a quién afecta
El reporte indica que la explotación “en el mundo real” comenzó en pocas horas tras la asignación de la CVE. Los objetivos incluyen instancias alojadas en la nube, lo que aumenta el alcance potencial debido a la facilidad de acceso y la escala habitual de despliegues.
En cuanto a versiones, la advertencia es clara: todas las versiones anteriores a 3.15.0 están afectadas. Por lo tanto, si su organización ejecuta MLflow en esas versiones y expone el servicio a redes no confiables, el riesgo debe tratarse como prioritario.
Qué recomienda hacer si usas MLflow
Si tu empresa utiliza MLflow, el enfoque recomendado se centra en reducir exposición y verificar indicios de compromiso. En concreto, se sugieren estas acciones:
- Aplicar parches cuanto antes: actualiza a una versión que corrija el problema (la referencia del reporte señala 3.15.0 como umbral).
- Revisar sistemas expuestos: identifica qué instancias del tracking server están accesibles desde Internet u otras redes no controladas.
- Auditar registros: revisa logs y eventos de seguridad en busca de actividad anómala, especialmente accesos relacionados con requests inusuales.
- Validar credenciales y secretos: comprueba si tokens, claves o secretos pudieron haber sido expuestos y aplica rotación cuando sea necesario.
Estas medidas no solo apuntan a detener el ataque actual, sino también a limitar el impacto si existió explotación previa.
Respuesta oficial: CISA añade la CVE a su catálogo KEV
El medio oficial de seguridad en Estados Unidos (CISA) incorporó CVE-2026-64849 a su catálogo Known Exploited Vulnerabilities (KEV). En ese marco, la recomendación es que las agencias federales apliquen los parches en un plazo de dos semanas, siguiendo las directrices mencionadas en el reporte.
La inclusión en KEV suele señalar que la vulnerabilidad ya está siendo explotada activamente y que, por tanto, el tiempo de respuesta importa de forma crítica.
Por qué este caso es una señal para entornos de IA
Más allá de MLflow, este incidente es una advertencia sobre cómo las plataformas de ingeniería de IA, al integrarse con despliegues en la nube, pueden convertirse en puertas de entrada hacia información de infraestructura. Una SSRF no autenticada, especialmente cuando puede consultar servicios internos o metadata, tiende a tener consecuencias desproporcionadas.
Para equipos de seguridad y operaciones, la lección es doble: mantener las versiones actualizadas y reducir superficies de exposición. En muchos entornos, el “tracking server” o componentes de orquestación quedan accesibles sin controles suficientes, y eso incrementa el riesgo cuando aparece una falla severa.
Checklist rápido para reducir el riesgo
Si necesitas una guía corta para actuar, usa este resumen:
- Confirma la versión de MLflow instalada y determina si es anterior a 3.15.0.
- Verifica el acceso de red al tracking server y a endpoints relacionados con webhooks del model-registry.
- Revisa logs buscando patrones de SSRF: solicitudes extrañas, destinos no habituales y respuestas inesperadas.
- Revisa secretos: rota credenciales potencialmente expuestas y valida permisos en la nube.
Conclusión
La vulnerabilidad en MLflow (CVE-2026-64849) muestra cómo un fallo de SSRF no autenticada puede convertirse en un mecanismo de robo de credenciales y secretos al alcanzar servicios de metadatos en entornos cloud. Dado que la explotación ya se observa en el mundo real y el problema afecta a versiones anteriores a 3.15.0, la prioridad debe ser actualizar, reducir exposición y auditar de forma inmediata.
Fuente: https://www.securityweek.com/mlflow-vulnerability-exploited-for-cloud-credential-theft/
