Un Ingeniero Levanta un Panel, Solo Para el Equipo

Un ingeniero de una empresa mediana levanta un servidor de seguimiento de MLflow en una VM interna para que el equipo de ciencia de datos registre experimentos y compare ejecuciones de modelos. MLflow no pide un nombre de usuario ni una contraseña durante la instalación, así que no se configura ninguna, y el servidor queda activo detrás de lo que todos asumen que es una red privada. En una fábrica a varios cientos de kilómetros, un ingeniero de operaciones hace algo parecido: levanta FUXA, una plataforma de código abierto SCADA y HMI, para dar al equipo una vista basada en navegador de las etiquetas de la línea de producción. Ninguno de los dos sistemas se construyó para ser alcanzable desde internet abierto, y ningún equipo lo comprobó.

En la semana del 18 de agosto de 2026, ambas suposiciones resultaron falsas a la vez. MLflow, una plataforma de seguimiento de experimentos alojada bajo LF Projects en la Linux Foundation, y FUXA, una herramienta de sistemas de control industrial sin relación alguna, divulgaron cada una una vulnerabilidad crítica, sin autenticación por defecto - y en ambos casos los atacantes tenían exploits funcionales en cuestión de horas tras la divulgación pública, no semanas. Dos bases de código distintas, dos sectores distintos, dos equipos que nunca se coordinaron entre sí. Lo que comparten es una única decisión de diseño, tomada de forma independiente, con años de diferencia, por la misma razón: es más rápido publicar una herramienta con la autenticación apagada que encendida.

El Fallo de MLflow Convierte una Redirección en un Robo de Credenciales

La vulnerabilidad de MLflow, registrada como CVE-2026-64849, tiene una puntuación CVSS de 9,3. Es un fallo de validación de URL de webhook: MLflow permite registrar webhooks que se disparan ante eventos como una ejecución de entrenamiento completada, y comprueba la dirección de destino antes de permitirlo, para evitar que el servidor apunte a direcciones internas. Los atacantes descubrieron que podían burlar esa comprobación combinando una redirección HTTP con DNS rebinding - registran un webhook hacia una dirección que pasa la validación, y luego, en el momento de la solicitud, esta se resuelve hacia una IP interna que el validador nunca vio. GitLab publicó un aviso de seguridad sobre el fallo, y el exploit fue corroborado de forma independiente por medios de ciberseguridad como cybersecuritynews, cyberpress y GBHackers.

La recompensa para un atacante es la falsificación de solicitudes del lado del servidor: el propio servidor MLflow pasa a ser quien hace la solicitud, desde dentro de la red en la que vive. Eso permite a un atacante alcanzar servicios internos que nunca debían mirar hacia afuera, y de forma crítica, los endpoints de metadatos de instancia en la nube de AWS, Azure y GCP - las direcciones internas que entregan credenciales temporales a la máquina que las solicita. Como los servidores de seguimiento de MLflow suelen funcionar sin autenticación en despliegues reales, nada impide que un atacante externo haga esa primera solicitud. The Hacker News informó el 18 de agosto de 2026 de que la explotación activa comenzó en cuestión de horas tras la divulgación.

El Fallo de FUXA Permite a Externos Escribir Archivos en Sistemas de Planta

FUXA es una plataforma de código abierto SCADA y HMI - el tipo de software que da a los operadores de planta una ventana de navegador sobre el equipo que realmente controla una línea de producción. Su vulnerabilidad, CVE-2026-25895, puntúa incluso más alto que la de MLflow, con 9,5, y el mecanismo es más directo: falta de autenticación combinada con un fallo de path traversal. Un atacante no autenticado puede enviar una solicitud que escapa del directorio en el que FUXA espera escribir y colocar un archivo en cualquier punto del sistema de archivos subyacente que elija.

La escritura arbitraria de archivos no es un simple fallo de exposición de datos, es un punto de apoyo. Un atacante que puede escribir archivos donde quiera en un sistema que se comunica con equipos industriales puede colocar código ejecutable y lograr ejecución remota de código, lo que significa control total del host que ejecuta la HMI - y, según cómo esté conectado ese host con la planta, un camino hacia los propios sistemas de control. Igual que con MLflow, The Hacker News y los mismos medios que lo corroboraron informaron de que la explotación activa comenzó en cuestión de horas tras la divulgación pública, la misma semana que el aviso de MLflow.

El Hilo Común No Es el Código, Es el Valor Por Defecto

MLflow y FUXA no comparten código, ni responsables, ni mercado. Uno registra experimentos de machine learning, el otro visualiza sistemas de control industrial, y se divulgaron de forma independiente en la misma semana por pura coincidencia de calendario. Lo que comparten es un valor por defecto: publicar sin autenticación, porque es la forma más rápida de poner en marcha una herramienta para un pequeño equipo interno, y porque el equipo asume que la red que la rodea es privada. Esa suposición es toda la superficie de ataque.

Ese mismo valor por defecto está detrás de buena parte de las herramientas internas que los propietarios nunca inspeccionan personalmente: paneles de MLOps, pilas de monitorización, paneles de administración internos, y sistemas SCADA/HMI en toda la industria manufacturera. Cada una probablemente se levantó rápido, por alguien competente, resolviendo un problema real, que nunca volvió para activar la autenticación porque nada le obligó a hacerlo. La brecha entre lo que se asume privado y lo que es realmente alcanzable - ya sea por exposición directa a internet o, como con MLflow, mediante un pivote SSRF desde un sistema que sí es alcanzable - es exactamente donde aterrizaron ambos exploits, y es donde aterrizará el siguiente.

Horas Hasta la Explotación Es Ya la Ventana de Parcheo Real

Para cualquier empresa de la UE o el Reino Unido que ejecute canalizaciones de MLOps - cada vez más habitual a medida que las compañías despliegan su propia infraestructura de ML e IA - o cualquier empresa industrial o manufacturera que ejecute sistemas SCADA o HMI, la respuesta práctica es una auditoría, no una nota de política. Cada herramienta interna necesita una respuesta directa a una pregunta: ¿está la autenticación realmente activada, no solo asumida, y es la herramienta realmente inalcanzable desde fuera de la red en la que se supone que vive? MLflow y FUXA muestran ambas que la respuesta honesta suele ser no, y que nadie lo descubre hasta que se explota.

El otro ajuste es el reloj. Ambos fallos pasaron de la divulgación pública a la explotación activa en horas, no en las semanas que los ciclos de parcheo asumían tradicionalmente. Para los operadores industriales con sede en la UE en concreto, esto no es solo un problema técnico: las obligaciones de NIS2 se aplican a los proveedores de infraestructura digital y, de forma notable, a los operadores manufactureros e industriales que ejecutan sistemas OT y SCADA, lo que convierte una HMI sin parchear y sin autenticación en un fallo de cumplimiento además de un fallo de seguridad. La solución no es exótica - activar la autenticación, parchear el día de la divulgación, asumir que nada detrás del cortafuegos es realmente privado - pero tiene que ocurrir antes de que ocurra el exploit, y esta semana esa brecha se midió en horas.

Leer a continuación: Una brecha que su registro DORA no puede explicar  |  Shell y Philips perdieron planos, no contraseñas