La plataforma de orquestación de LLM dejó accesible información sensible de múltiples organizaciones a cualquier usuario autenticado, sin parche disponible.
Una falla de diseño en Flowise — plataforma open-source para construir flujos de trabajo con modelos de lenguaje — permite que cualquier usuario con credenciales válidas acceda a datos confidenciales de todas las organizaciones alojadas en la misma instancia. La vulnerabilidad, catalogada como CVE-2026-100608 con severidad alta por el National Vulnerability Database, afecta a la versión 3.1.4 y todas las anteriores cuando el servidor opera en modo de colas con el dashboard administrativo habilitado. Al momento de este análisis no existe versión corregida disponible.
El problema radica en que el endpoint /admin/queues — que expone la interfaz completa de Bull-Board para gestionar colas de procesamiento — valida únicamente que el token JWT sea legítimo, sin verificar roles, permisos ni a qué workspace u organización pertenece el usuario. Cualquier cuenta autenticada, incluso con privilegios mínimos en un tenant específico, puede visualizar y manipular las colas de trabajo de toda la instancia.
Cómo una validación incompleta rompe el aislamiento entre tenants
La arquitectura de Flowise separa el tráfico de API bajo la ruta /api/v1/*, donde sí opera un gateway global que aplica controles de autorización. El dashboard de BullMQ, en cambio, se monta directamente en /admin/queues — fuera de ese perímetro protegido — y depende exclusivamente del middleware verifyTokenForBullMQDashboard. Este componente verifica que el JWT sea válido pero no cruza esa identidad contra ningún registro de permisos ni contra el scope de workspace u organización al que debería estar limitado el usuario.
La condición para que la falla sea explotable requiere tres parámetros de configuración simultáneos: MODE=queue (el servidor procesa trabajos en segundo plano mediante colas), ENABLE_BULLMQ_DASHBOARD=true (el dashboard administrativo está activo) y que la instancia no esté corriendo en modo cloud (!isCloud()). En despliegues on-premise o self-hosted que cumplan esas condiciones, el aislamiento entre tenants desaparece por completo en este endpoint.
Qué información queda expuesta en las colas de procesamiento
Los payloads de los jobs almacenados en las colas de BullMQ contienen el estado completo de cada flujo de trabajo en ejecución. Esto incluye los inputs de chat enviados por usuarios finales, el objeto overrideConfig que puede transportar credenciales de APIs externas y system prompts personalizados, y el grafo chatflow.flowData con las definiciones de cada nodo del flujo — incluyendo el código fuente de funciones personalizadas escritas en JavaScript.
También quedan visibles los identificadores de credenciales almacenadas (credential IDs), los chatIds que permiten rastrear conversaciones específicas, archivos adjuntos procesados y los metadatos orgId y workspaceId que identifican a qué organización y espacio de trabajo pertenece cada job. Un atacante con acceso al dashboard puede reconstruir la topología completa de flujos de trabajo de otros tenants, extraer prompts de sistema que suelen contener lógica de negocio sensible y potencialmente obtener tokens de acceso a servicios de terceros si estos viajan en overrideConfig.
Acciones de escritura utilizables entre organizaciones
Más allá de la lectura, la interfaz de Bull-Board expone controles para reintentar jobs fallidos (retry), eliminarlos de la cola (remove), promoverlos a ejecución inmediata (promote) y limpiar colas completas (clean). Dado que el middleware no valida ownership, un usuario de la organización A puede ejecutar estas operaciones sobre jobs pertenecientes a la organización B. Esto abre vectores de denegación de servicio (eliminar o limpiar colas ajenas) y de manipulación de flujos de trabajo (forzar la ejecución de un job con parámetros ya conocidos por haber sido leídos previamente).
El impacto en América Latina es directo para las empresas que operan instancias multi-tenant de Flowise en la región. Proveedores de servicios de IA conversacional en México y Brasil que alojan flujos de múltiples clientes en la misma infraestructura quedan expuestos a filtraciones cruzadas de datos si alguno de esos clientes logra autenticarse con credenciales válidas — incluso si se trata de una cuenta de prueba con permisos restringidos. La ausencia de parche obliga a desactivar el dashboard o migrar a arquitecturas de tenant único hasta que se publique una corrección.
Nuestro análisis
Esta vulnerabilidad ejemplifica un patrón recurrente en plataformas que integran componentes de terceros con modelos de autenticación propios: la validación de identidad (¿este token es legítimo?) no equivale a la validación de autorización (¿este usuario puede ver estos datos?). El hecho de que el endpoint /admin/queues esté fuera del scope del API gate sugiere que se agregó como una herramienta de administración sin pasar por el mismo proceso de revisión de seguridad que el resto de la API. La decisión de montar Bull-Board directamente en una ruta pública, en lugar de exponerlo únicamente en localhost o tras un proxy inverso con autenticación adicional, amplifica el radio de exposición.
La ausencia de versión parcheada al momento del advisory — publicado por el NVD sin indicación de timeline de corrección — deja a los operadores de instancias afectadas en una posición de mitigación manual: deshabilitar ENABLE_BULLMQ_DASHBOARD, restringir el acceso a /admin/queues mediante reglas de firewall o proxy, o migrar a despliegues de tenant único donde la falta de scoping no implique exposición cruzada. Ninguna de estas opciones es trivial en entornos de producción con múltiples clientes ya operando. ¿Cuántas plataformas de orquestación de IA en la región están corriendo con dashboards administrativos expuestos sin validación de permisos, confiando únicamente en que «nadie debería conocer esa URL»?