Índice de contenidos
Claves de la noticia
- Sekoia publica una investigación sobre intentos de abuso contra un señuelo que imitaba Flowise.
- La documentación de Flowise distingue la autenticación de la aplicación del acceso a cada flujo.
- Los avisos históricos de CustomMCP y CSV Agent requieren comprobar versiones y componentes concretos.
Sekoia ha divulgado este 19 de octubre un informe sobre un atacante que intentó aprovechar una plataforma de agentes de IA. El experimento imitaba Flowise, pero no ejecutaba un modelo real. Esa condición delimita su alcance: permite estudiar peticiones hostiles, sin demostrar que un asistente produjera las acciones solicitadas.
Un incidente de agosto divulgado ahora
El informe de Jérémy Scion y el equipo TDR describe actividad de finales de agosto, distribuida primero a clientes el 7 de septiembre. El señuelo reproducía una instancia de Flowise 2.2.8 con accesos deliberadamente abiertos y credenciales ficticias. Registró extracción de esos secretos e intentos de alterar flujos y pedir ayuda ofensiva al supuesto agente.
La evidencia acredita las peticiones del atacante. Como el sistema tampoco ejecutaba código real, no permite deducir una intrusión efectiva en una base de datos empresarial. Para valorar una alerta similar en producción hace falta reconstruir qué acceso estaba permitido y qué operación llegó a ejecutarse.
Dos puertas de acceso con funciones diferentes
La guía oficial de autenticación de aplicación documenta un sistema basado en Passport.js desde la versión 3.0.1. Valida correo y contraseña, utiliza tokens JWT y mantiene sesiones. También advierte de que los secretos de firma deben configurarse con valores propios: conservar los predeterminados puede facilitar la suplantación. Es una propiedad que conviene comprobar en la configuración efectiva del servicio, además de verificar que aparece una pantalla de inicio de sesión.
El control de acceso de un chatflow resuelve otra cuestión: quién puede invocar un flujo determinado. La documentación indica que, por defecto, quien conoce su identificador puede ejecutar predicciones mediante API o integración web; asignarle una clave obliga a presentar la cabecera de autorización correspondiente. El identificador sirve para localizar el flujo y no equivale a una contraseña.
La distinción tiene una consecuencia práctica para quien integra un chatbot en una web: comprobar el panel de administración no basta para describir cómo se admite una consulta pública. Deben revisarse ambas superficies con sus respectivas reglas. Tampoco sería correcto convertir la exposición intencionada del señuelo en una afirmación sobre todas las instalaciones de Flowise.
La referencia de administración de flujos añade operaciones para listar, consultar, actualizar, crear y borrar configuraciones, bajo un esquema de autenticación bearer. Ese inventario permite formular preguntas concretas al responsable del despliegue: qué identidad puede cambiar un flujo, qué permisos conserva y cómo se detecta una modificación inesperada. La revisión debe abarcar la escritura de configuraciones, además del uso del chat.
Tres controles que no se sustituyen
La siguiente comparación reúne funciones documentadas por el proyecto. Su utilidad es evitar que una comprobación satisfactoria se interprete como garantía de las demás.
| Control | Qué comprobar | Límite |
|---|---|---|
| Autenticación | Sesión y clave del flujo | No corrige código vulnerable |
| Frecuencia | Solicitudes por IP y período | No identifica al usuario |
| Componentes | Versiones y avisos aplicables | No sustituye los permisos |
Flowise permite limitar solicitudes por dirección IP, fijando cantidad, intervalo y respuesta al superar el umbral. Su ejemplo admite veinte mensajes en sesenta segundos. Esa cifra es ilustrativa, no una recomendación universal. La misma guía exige revisar el número de proxies cuando existe un balanceador: si el servicio interpreta mal la dirección del cliente, el límite puede no comportarse como se espera.
De ahí surge una comprobación diferenciada: una clave decide quién entra; un límite restringe cuánto consume. Reducir consultas no revoca una credencial robada. La necesidad de revisar permisos y secretos también aparece en el incidente de Cloud Backup de ConnectWise, aunque se trate de otro producto y otro acontecimiento.
Los parches históricos tienen un alcance preciso
El aviso de CustomMCP, publicado en septiembre de 2025, describe ejecución de JavaScript al procesar una configuración suministrada por el usuario. Identifica Flowise 3.0.5 como versión afectada y 3.0.6 como corregida. El fallo corresponde al procesamiento de configuración con privilegios del entorno Node.js; su explicación no depende de atribuir intención al modelo.
El aviso de CSV Agent, publicado el 15 de abril de 2026, trata otro recorrido: evaluación de Python generado por un LLM sin aislamiento adecuado. Señala versiones hasta 3.0.13 y una corrección en 3.1.0 para Flowise y flowise-components. Son referencias históricas, no una recomendación de instalar hoy esas versiones. Compararlas muestra por qué revisar solo el paquete principal puede dejar incompleto el inventario de componentes afectados.
De la petición a la acción comprobable
La API de predicción distingue el texto de respuesta de los documentos recuperados y de las herramientas utilizadas, recogidas en el campo usedTools. Para investigar un incidente, ese detalle ofrece un punto de contraste con los registros del servicio y del destino. No convierte por sí solo la respuesta de la API en una auditoría completa.
El criterio operativo resultante es concreto: registrar una instrucción hostil exige revisar la entrada; confirmar una acción exige comprobar también la herramienta y su efecto. Esa separación ayuda a contener un servicio expuesto sin exagerar sus consecuencias ni dar por resuelto el problema únicamente porque el chatbot responda con normalidad.
Imagen conceptual generada con IA; no representa el experimento de Sekoia.
