MLflow y FUXA bajo ataque: explotan fallos críticos en IA y automatización industrial

Escaneos activos contra servidores MLflow e instalaciones FUXA

Se están produciendo escaneos e intentos de explotación contra instalaciones expuestas de MLflow, una plataforma open source para gestionar flujos de machine learning, y FUXA, un software web SCADA/HMI utilizado en entornos OT e industriales.

La actividad ha sido observada por watchTowr y VulnCheck. En el caso de MLflow, los escaneos comenzaron pocas horas después de la asignación de CVE-2026-64849, el 17 de agosto de 2026. Para FUXA, VulnCheck detectó actividad maliciosa el 18 de agosto de 2026, procedente de una dirección IP que buscaba sistemáticamente instalaciones accesibles desde Internet.

Las estimaciones disponibles apuntan a unas 60 instalaciones FUXA expuestas públicamente. Las solicitudes observadas intentaban sobrescribir el archivo main.js mediante la vulnerabilidad CVE-2026-25895. Hasta ahora no se han identificado payloads de ejecución de código depositados durante esta actividad, pero la técnica puede preparar el compromiso completo del servidor.

Las dos plataformas presentan perfiles de riesgo diferentes. MLflow puede convertirse en un punto de acceso a credenciales cloud y servicios internos; FUXA puede exponer directamente sistemas de automatización, dispositivos ICS y procesos industriales.

MLflow: una SSRF permite leer servicios internos y metadatos cloud

La vulnerabilidad CVE-2026-64849 es una Server-Side Request Forgery, o SSRF, no autenticada. Afecta al sistema de entrega de webhooks del Model Registry y puede ser explotada por cualquier persona capaz de alcanzar el Tracking Server de MLflow.

El endpoint afectado es:

POST /api/2.0/mlflow/webhooks/{id}/test

Un atacante puede inducir al servidor a realizar solicitudes HTTP hacia direcciones loopback, hosts internos, interfaces administrativas y servicios de metadatos de infraestructuras cloud. La respuesta upstream se devuelve posteriormente desde el endpoint de prueba, incluido el estado HTTP y el contenido.

Por tanto, no se trata de una SSRF “ciega”. El atacante puede leer directamente aquello a lo que accede el servidor, incluidos tokens IAM, credenciales temporales y otros secretos presentes en servicios cloud. La puntuación indicada en el registro es CVSS 9.3, con el siguiente vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N

El problema surge de la interacción de varios fallos en la gestión de destinos. La función _validate_webhook_url, introducida en la versión 3.10.0, resuelve el nombre del host y bloquea direcciones privadas, loopback, link-local y endpoints de metadatos. Sin embargo, la dirección validada no queda vinculada a la conexión posterior.

Además, el servidor sigue las redirecciones porque la sesión HTTP no establece allow_redirects=False, mientras que el destino indicado por la redirección no se somete a una nueva validación. Esto también permite escenarios de DNS rebinding, en los que el host resuelve a una dirección pública durante la comprobación y a un recurso interno en el momento de la conexión.

Por ejemplo, un endpoint HTTPS público puede responder con una redirección 302 hacia:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

También son posibles redirecciones 307 o 308, que conservan el método y el cuerpo de la solicitud y pueden permitir variantes con escritura en el destino interno.

La vulnerabilidad se ha confirmado en mlflow==3.13.0, con la base de datos SQLite predeterminada. No se requiere autenticación: en el servidor estándar, los webhooks no están protegidos, mientras que los controles de autorización solo están disponibles mediante un plugin opcional que no se carga automáticamente.

Las indicaciones sobre las versiones no están completamente alineadas. Un umbral operativo considera vulnerables las versiones anteriores a la 3.15.0, mientras que el advisory técnico confirma el impacto en 3.13.0 y anteriores sin indicar en la ficha una versión corregida. La solución está asociada a la pull request #24258 y al commit ba94952247, que introduce SSRFProtectedHTTPAdapter.

El nuevo adapter comprueba la IP del socket inmediatamente después de la conexión y antes del intercambio TLS/HTTP. Las redirecciones también pasan por el mecanismo protegido, lo que impide el bypass mediante redireccionamiento y DNS rebinding.

FUXA: escritura arbitraria de archivos y posible ejecución de código

CVE-2026-25895 afecta a FUXA hasta la versión 1.2.9 incluida. La corrección está disponible en la versión 1.2.10.

El fallo combina path traversal y ausencia de autenticación en una función crítica. Un atacante remoto no autenticado puede escribir archivos arbitrarios en rutas elegidas del sistema de archivos del servidor, incluso cuando runtime.settings.secureEnabled está establecido en true.

El riesgo incluye la sobrescritura de archivos de la aplicación, configuraciones y scripts de arranque. Si un archivo modificado se carga o ejecuta posteriormente, la escritura puede convertirse en ejecución remota de código. La gravedad depende de los privilegios del proceso FUXA y de sus conexiones con redes OT y sistemas SCADA.

La evaluación del advisory asigna CVSS 4.0 de 9.5, con un impacto elevado en la confidencialidad, integridad y disponibilidad del sistema vulnerable y de los sistemas posteriores. El registro también incluye una valoración CVSS 3.1 de 9.8:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Durante los escaneos observados, el intento consistía en sobrescribir main.js con datos sin significado. La ausencia de un payload de RCE en la fase detectada no reduce la prioridad: demuestra que los atacantes ya están alcanzando la función vulnerable y comprobando su comportamiento.

El problema es distinto de CVE-2025-69981, relacionada con una función de carga insegura. Esa funcionalidad estaba protegida mediante autenticación; la vulnerabilidad actual es el path traversal que permite la escritura arbitraria.

FUXA: bypass de autorización para los schedulers industriales

FUXA también presenta CVE-2026-25939, un bypass de autorización clasificado como CWE-862. Las versiones afectadas son las anteriores a la 1.2.11; la corrección indicada es FUXA 1.2.11.

El fallo permite a un usuario remoto no autenticado crear o modificar schedulers arbitrarios. En las versiones de la 1.2.8 a la 1.2.10, esta capacidad puede utilizarse para preparar acciones posteriores contra entornos ICS y SCADA conectados.

La puntuación es CVSS 9.1:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

La principal consecuencia afecta a la integridad y la disponibilidad: un scheduler alterado puede modificar el comportamiento previsto de las instalaciones o iniciar operaciones no autorizadas. No hay disponibles más indicadores técnicos sobre los intentos observados contra esta vulnerabilidad.

La actividad contra FUXA forma parte de una campaña más amplia. También se ha observado la explotación de CVE-2023-33831, valorada en CVSS 9.8, con el siguiente vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Según la información disponible, esta actividad habría comenzado en noviembre de 2025 y continuado hasta el periodo inmediatamente anterior a la detección. No se conocen más detalles sobre el vector o los indicadores.

Qué comprobar y cómo reducir la exposición

Los administradores deben actualizar FUXA al menos a la 1.2.10 para CVE-2026-25895 y a la 1.2.11 para CVE-2026-25939. Para MLflow debe aplicarse la corrección asociada a la PR #24258; el umbral de actualización indicado operativamente es la 3.15.0, mientras que la confirmación técnica disponible se refiere a la versión 3.13.0.

Siempre que sea posible, MLflow y FUXA no deben exponerse directamente a Internet. El acceso debe limitarse mediante segmentación de red, autenticación robusta y reglas de firewall que impidan al servidor acceder libremente a servicios internos.

En MLflow deben analizarse los logs relativos a:

• creación y modificación de webhooks;
• llamadas a /api/2.0/mlflow/webhooks;
• uso del endpoint /test;
• redirecciones procedentes de hosts HTTPS públicos;
• solicitudes hacia 169.254.169.254, 127.0.0.1 y direcciones RFC1918.

También deben comprobarse posibles accesos a tokens IAM, credenciales cloud, secretos de aplicaciones y servicios administrativos. Cualquier credencial potencialmente expuesta debe revocarse y sustituirse.

En FUXA es necesario buscar solicitudes con traversal, modificaciones inesperadas de main.js, escrituras anómalas en el sistema de archivos y cambios no autorizados en los schedulers. Los sistemas conectados deben revisarse para detectar archivos alterados, nuevas tareas programadas y comandos o cambios de proceso no previstos.

Para estas vulnerabilidades no se indica presencia en el catálogo CISA KEV, ni existe un plazo de remediación establecido por CISA. Por tanto, actualmente no hay una fecha límite KEV específica.