CVE-2026-100608 in Flowise
Summary
by MITRE • 09/26/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Flowise versions prior to 3.1.4 represents a critical failure in access control mechanisms within the BullMQ administration dashboard interface. This flaw stems from an insufficient authorization check that allows authenticated users to bypass intended isolation boundaries between different tenants or workspaces. The root cause lies in the specific configuration of the server when operating in queue mode with the dashboard enabled, specifically under conditions where MODE is set to queue and ENABLE_BULLMQ_DASHBOARD is true while not running in cloud mode. In this operational context, the administrative endpoint mounted at /admin/queues relies exclusively on a middleware function named verifyTokenForBullMQDashboard for security validation. This middleware performs only basic authentication by verifying the validity of a JSON Web Token but completely lacks any subsequent authorization logic to validate user roles, permissions, or scoping against specific organizations or workspaces.
This architectural oversight is compounded by the fact that this administrative mount point resides outside the standard /api/v1/* route structure. Consequently, it bypasses global API gateway protections and other centralized security policies typically applied to application endpoints. The result is a severe breakdown in multi-tenancy isolation where any user possessing a valid authentication token for Flowise can access the full BullBoard interface regardless of their assigned privilege level. Even users with minimal or lowest-level privileges are granted unrestricted visibility into system-wide queue data, effectively nullifying the security model designed to separate tenant-specific operations and data.
The operational impact of this vulnerability is extensive due to the sensitive nature of the data exposed through the dashboard. Users can view all queues and job payloads across the entire instance without restriction. This exposure includes highly confidential information such as chat inputs, override configurations which may contain embedded credentials or system prompts, complete chatflow graph definitions containing custom function source code, credential identifiers, system prompt text, unique chat session identifiers, uploaded files, and organizational workspace IDs. The breadth of this data leakage means that an attacker could potentially extract proprietary logic, sensitive customer interactions, and authentication secrets from multiple tenants simultaneously through a single authenticated account belonging to any user within the organization.
Furthermore, the vulnerability extends beyond passive information disclosure to include active manipulation capabilities. The dashboard provides write actions such as retrying failed jobs, removing existing jobs, promoting pending tasks, and cleaning up completed entries. These operations are also accessible across tenant boundaries without proper authorization checks. An attacker could therefore disrupt service availability for other tenants by manipulating job queues or potentially execute malicious code if the queue processing logic is susceptible to injection through manipulated payload data. This combination of unauthorized read access and write capability creates a significant risk to both confidentiality and integrity within the multi-tenant environment.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Escalation as it allows users to act beyond their assigned privileges by accessing administrative functions reserved for higher-level roles or specific tenants. It also corresponds closely to CWE-862 Missing Authorization since the application fails to enforce proper access controls on a protected resource. In terms of offensive security frameworks, this behavior maps directly to MITRE ATT&CK technique T1078 Valid Accounts, where an attacker leverages legitimate credentials to gain unauthorized access to resources, and potentially T1530 Data from Cloud Storage if the exposed data is considered part of cloud-based operational storage mechanisms.
As there are no patched versions available as indicated in current advisories, mitigation strategies must focus on immediate configuration changes and network-level controls. Administrators should disable the BullMQ dashboard entirely by setting ENABLE_BULLMQ_DASHBOARD to false unless absolutely necessary for debugging or monitoring purposes. If the dashboard is required, it should be isolated behind additional authentication layers such as IP whitelisting using firewall rules or reverse proxy configurations that restrict access to trusted administrative networks only. Implementing a Web Application Firewall with specific rule sets to block unauthorized requests to the /admin/queues path can also provide an interim layer of defense until a software patch is released by the vendor.