Índice de contenidos
La agencia estadounidense CISA ha incorporado CVE-2026-64849 a su catálogo de vulnerabilidades explotadas, después de observar ataques contra despliegues de MLflow. El fallo, corregido en MLflow 3.15.0, permite eludir la validación de direcciones de webhooks mediante redirecciones HTTP o cambios de resolución DNS. Un atacante capaz de crear o activar el webhook puede convertir el servidor en intermediario para consultar destinos internos y servicios de metadatos que no deberían estar expuestos.
Claves de la noticia
- CVE-2026-64849 afecta a versiones de MLflow anteriores a 3.15.0 y ya se explota en entornos reales.
- El problema es una falsificación de solicitudes del lado del servidor que atraviesa la validación mediante redirecciones o DNS rebinding.
- La prioridad es actualizar, rotar credenciales potencialmente accesibles y revisar webhooks y conexiones realizadas por el servicio.
Cómo funciona la vulnerabilidad
MLflow permite registrar webhooks para avisar a otros servicios cuando cambia un modelo, experimento o registro. La aplicación intenta impedir destinos privados, pero validaba la URL inicial sin volver a comprobar adecuadamente el punto final alcanzado después de una redirección. Un dominio controlado por el atacante podía responder con un salto hacia una dirección interna. El servidor de MLflow realizaba entonces la petición desde una posición de red privilegiada.
El DNS rebinding explota una idea relacionada: un nombre resuelve primero a una dirección permitida y después a otra privada. Si cada conexión no valida de nuevo la resolución, la comprobación y el uso observan destinos diferentes. El impacto exacto depende de la red. En una nube, un endpoint de metadatos puede entregar credenciales temporales; en un centro de datos, el acceso puede revelar paneles, APIs o información de servicios solo internos.
Por qué un servidor de MLOps es un objetivo valioso
MLflow se usa para rastrear experimentos, registrar modelos y coordinar su paso a producción. Puede tener acceso a almacenes de objetos, repositorios, bases de datos y plataformas cloud. Incluso cuando la vulnerabilidad no ejecuta código directamente, una solicitud interna puede obtener tokens o descubrir servicios con autenticación débil. Esas credenciales pueden abrir un camino hacia datos de entrenamiento, artefactos o capacidad de cálculo.
Los despliegues varían mucho. Algunos están detrás de una VPN; otros exponen interfaces a Internet o permiten que equipos amplios creen integraciones. Por eso una puntuación general no describe todos los casos. La confirmación de explotación sí cambia la prioridad: los atacantes ya conocen la técnica y buscarán instalaciones accesibles. Los equipos deben comprobar versión real de cada nodo y no asumir que un proxy frontal corrige una solicitud que sale desde el backend.
Actualización y búsqueda de indicios
La versión 3.15.0 corrige el comportamiento y debe instalarse siguiendo la ruta de actualización del proyecto. Antes de reiniciar, conviene preservar logs de webhooks, DNS, proxy y nube. Los administradores deben buscar destinos inesperados, respuestas de redirección y conexiones a rangos internos o endpoints de metadatos. Un webhook creado y borrado puede dejar pocos rastros en la interfaz, de modo que la telemetría externa resulta valiosa.
Si el servicio alcanzaba credenciales temporales, hay que revocarlas o rotar las identidades relacionadas y revisar acciones posteriores. Las políticas de red pueden bloquear desde MLflow el acceso a metadatos y segmentos no necesarios. Esa defensa reduce impacto incluso ante fallos futuros. También es recomendable exigir autenticación para crear webhooks, limitar el permiso a pocos roles y revisar integraciones como código.
Qué significa entrar en el catálogo KEV
CISA no añade un CVE al catálogo solo por su severidad; requiere evidencia fiable de explotación. Las agencias federales deben corregir los elementos afectados dentro del plazo indicado por la directiva aplicable. Para empresas privadas, KEV es una señal práctica para ordenar el trabajo: un fallo utilizado suele merecer prioridad sobre vulnerabilidades teóricas con una puntuación parecida.
La inclusión no identifica por sí sola a los atacantes, el número de víctimas ni el objetivo final. Tampoco prueba que toda instalación antigua haya sido comprometida. Sí elimina la comodidad de esperar. MLflow forma parte de una cadena donde modelos y secretos empresariales se mezclan; actualizar, restringir salida y revisar actividad son acciones complementarias. El parche cierra el defecto conocido, mientras la investigación decide si alguien lo utilizó antes.
Qué conviene seguir
A partir de ahora, la señal más útil será la que aporten el proveedor y los equipos de respuesta con indicadores verificables, versiones afectadas y una cronología completa. Las organizaciones no deberían esperar a conocer una atribución para inventariar su exposición, conservar registros y aplicar la corrección disponible. También conviene documentar las decisiones tomadas: qué sistemas se revisaron, qué credenciales se cambiaron y qué evidencias permiten descartar o confirmar intrusión. Esa disciplina evita dos errores opuestos, minimizar una alerta activa y declarar un compromiso sin pruebas. Cuando aparezcan nuevos detalles, deberán compararse con la configuración real de cada entorno, porque un mismo fallo o campaña puede tener consecuencias distintas según permisos, conectividad y datos accesibles. La comunicación a usuarios y responsables debe separar con claridad la posibilidad técnica, los ataques observados y el daño confirmado. Esa separación permite responder con rapidez sin convertir la incertidumbre inicial en afirmaciones que luego resulten difíciles de corregir.
