Description

Flowise through 3.1.4 does not enforce authorization on the BullMQ admin dashboard. When the server runs in queue mode with the dashboard enabled and not in cloud mode (MODE=queue, ENABLE_BULLMQ_DASHBOARD=true, and !isCloud()), the /admin/queues mount is protected only by the verifyTokenForBullMQDashboard middleware, which validates the JWT but performs no role, permission, or workspace/organization scoping check; the mount also lies outside /api/v1/* so the global API gate does not apply. As a result, any authenticated user — including the lowest-privileged member of any tenant — can reach the full Bull-Board UI and view all queues and job payloads across the entire instance, including chat inputs and overrideConfig (which may carry credentials and prompts), chatflow.flowData graph definitions with custom function source code, credential IDs and system prompts, chatIds, files, and the originating orgId/workspaceId. The dashboard's write actions (retry, remove, promote, clean) are likewise usable across tenants. No patched version is available as of the advisory.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.3",
  "pubDate": "2026-09-26T14:16:41.140Z",
  "pubdate": "2026-09-26T14:16:41.140Z",
  "executiveSummary": "Flowise versions up to 3.1.4 contain a critical authorization bypass vulnerability in the BullMQ dashboard component.\nThe vulnerability occurs when the application is deployed in queue mode (MODE=queue) with the dashboard enabled (ENABLE_BULLMQ_DASHBOARD=true).\nBecause the /admin/queues route bypasses the global API gateway and utilizes an insufficient authorization middleware, any authenticated user can gain full access to the Bull-Board management interface.\nThis allows unauthorized users to read sensitive job data, including chat inputs, system prompts, and configuration data across all tenants, as well as perform administrative actions such as job manipulation.\nThe risk is severe as it enables unauthorized disclosure of proprietary data and potential disruption of service workflows for all organizations on the instance.\nExploitation requires a valid user session on the affected instance, but does not require administrative privileges, making it a significant privilege escalation and information disclosure risk.",
  "technicalDetails": "The vulnerability resides in the misconfiguration of access controls for the Bull-Board UI in Flowise 3.1.4 and earlier. When the system operates in queue mode, the /admin/queues route is exposed via a dedicated middleware, verifyTokenForBullMQDashboard.\nThe root cause is an authentication-only check that fails to perform authorization validation. While the middleware verifies the presence of a valid JWT, it fails to enforce role-based access control (RBAC) or tenant-level isolation. Furthermore, because this route is mounted outside the /api/v1/* path, it is excluded from the application's global API security gate that typically enforces scoping and organization-based access constraints.\nThe attack flow begins with an authenticated user identifying the /admin/queues endpoint. Upon accessing this URL, the verifyTokenForBullMQDashboard middleware validates the user's token. Since the middleware only checks if the token is valid and not if the user has administrative or privileged access, the request is granted. The Bull-Board UI then renders, providing a full view of the message queues managed by the system.\nPost-exploitation, an attacker can access sensitive information stored within job payloads, including chat session data, flow definitions (chatflow.flowData), custom function source code, credential identifiers, and system-wide prompts. Additionally, the attacker gains the ability to execute write operations, such as retrying, removing, promoting, or cleaning jobs. Because these operations are global to the queue instance, an attacker can impact data belonging to any tenant, effectively breaking multi-tenancy boundaries.\nThe vulnerability is inherent to the server configuration when the following conditions are met: MODE=queue, ENABLE_BULLMQ_DASHBOARD=true, and the instance is not in cloud mode (!isCloud()). No specific network exposure is required beyond access to the web interface, and the attack is performed directly through the browser or via automated HTTP requests to the dashboard route."
}