Flowise EUVD-2026-87703

Requires the server to be started with the specific non-default configuration MODE=queue AND ENABLE_BULLMQ_DASHBOARD=true AND running not in cloud mode (!isCloud()); default single-process/cloud deployments are not exposed. Given that configuration, the only attacker prerequisite is any valid authenticated JWT - even the lowest-privileged member of any tenant - because the /admin/queues mount is guarded solely by verifyTokenForBullMQDashboard, which checks token validity but not role, permission, or workspace/organization scope, and the mount lies outside the /api/v1/* global authorization gate. No user interaction, no admin role, and no per-tenant membership in the victim tenant are needed; the limiting factor is entirely the queue-mode + dashboard-enabled + non-cloud deployment combination.

This is a genuine authorization bypass (CWE-862), not an authentication bypass as tagged: the verifyTokenForBullMQDashboard middleware correctly validates the JWT but performs no role, permission, or workspace/organization scoping, and the /admin/queues mount sits outside the /api/v1/* global API gate. The vendor CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:N, VC:H/VI:H/VA:L, score 8.7) is internally consistent with the description: network-reachable, low complexity, requiring only a low-privileged authenticated account. No EPSS score, KEV listing, or public POC was provided, so exploitation status is: no public exploit identified at time of analysis - the 8.7 reflects impact severity, not observed exploitation. The most important limiting signal is NOT in the raw CVSS but in the description: exploitation requires a specific non-default runtime configuration (MODE=queue, ENABLE_BULLMQ_DASHBOARD=true, and not cloud mode). This meaningfully narrows the real-world exposed population versus what an 8.7 alone implies. Where reachable, however, impact is real and cross-tenant (credential IDs, system prompts, custom function source, chat inputs/overrideConfig that may carry credentials, plus write actions), so for instances actually running queue mode with the dashboard enabled this is a legitimate high priority; for the typical default single-instance deployment it does not apply at all. No patch is available as of the advisory, which raises residual risk for affected configurations. VA:L/I is somewhat generous - write actions are limited to queue-job manipulation (retry/remove/promote/clean) rather than full system integrity/availability compromise.

An attacker registers or already holds the lowest-privileged member account in any tenant on a Flowise instance running in queue mode with the BullMQ dashboard enabled (non-cloud). Using their valid JWT, they browse directly to /admin/queues - which bypasses the tenant-scoped API gate - and read every queue's job payloads across all tenants, harvesting credential IDs, system prompts, chatflow graph definitions with custom function source, and chat inputs/overrideConfig that may contain secrets, while also being able to retry/remove/promote/clean other tenants' jobs. No public exploit code was identified at time of analysis; exploitation requires only a browser and a low-privileged session.