Summary
Flowise does not enforce role, permission, or tenant scoping for the BullMQ administration dashboard when queue mode is enabled outside cloud deployments. As a result, any authenticated user, including a low-privileged tenant member, may view queue data and use job-management actions across the instance.
Affected context
The vulnerability occurs in Flowise deployments where queue mode and the BullMQ dashboard are enabled outside cloud mode. The dashboard is mounted at /admin/queues, outside the global /api/v1/* authorization boundary, and its token middleware validates authentication without enforcing roles, permissions, or workspace and organization scope.
Exploit preconditions
- Attack surface: The BullMQ administration dashboard at
/admin/queues - Required access: A valid authenticated Flowise account; elevated privileges are not required
- Deployment condition: Queue mode is enabled, the BullMQ dashboard is enabled, and the deployment is not operating in cloud mode
- Trigger point: Access to the dashboard and its queue-management endpoints
- Why exploitation is possible: Authentication is checked, but authorization and tenant boundaries are not enforced for dashboard reads or write actions
Why this happens
The underlying issue is a missing authorization check, corresponding to CWE-862: Missing Authorization. The dashboard middleware verifies that a request carries a valid JWT but does not evaluate the user's role, permissions, workspace, or organization before granting access. Because the dashboard is outside the global API authorization path, authenticated users can access instance-wide queue data and operations without appropriate scope enforcement.
Potential impact
- Sensitive job payloads may be disclosed across tenants
- Chat inputs, prompts, files, credentials, identifiers, and workflow definitions could be exposed
- Custom function source code and other implementation details may be revealed
- Users may retry, remove, promote, or clean jobs belonging to other organizations
- Cross-tenant data integrity and workflow availability could be affected
- Exposed secrets or system prompts could support further compromise
General mitigation guidance
Mitigation generally focuses on applying authorization consistently to every administrative route and action, rather than relying only on token validity.
Defensive patterns include:
- Enforcing role- and permission-based access checks for dashboard access and each write operation
- Applying workspace and organization scoping to queue listings, job payloads, and job actions
- Placing administrative routes behind the same centralized authorization boundary as other protected APIs
- Using secure-by-default configuration that keeps administrative dashboards disabled unless explicitly required
- Minimizing sensitive data stored in queue payloads and redacting secrets before persistence
- Applying least privilege to tenant users and service identities
- Auditing existing sessions and access logs when cross-tenant dashboard exposure is possible
How teams detect issues like this
Organizations can identify similar authorization weaknesses through:
- Static analysis and route reviews that locate administrative mounts outside centralized API gates
- Code review checks confirming that authentication middleware is followed by role, permission, and tenant-scope enforcement
- Testing requests with low-privileged accounts from separate workspaces or organizations
- Authorization matrix tests covering dashboard reads and every queue-management action
- Runtime monitoring for access to administrative paths by non-administrative identities
- Policy checks requiring explicit protection for administrative interfaces and non-API routes
- Automated security review tools that flag token-only middleware on privileged endpoints
