Flowise EUVD-2026-87704

Requires a valid authenticated account on a multi-tenant/multi-workspace Flowise instance (PR:L) and knowledge of a credential UUID belonging to a different workspace - this UUID knowledge is the key limiting factor (reflected as AT:P), since UUIDs are unguessable and not enumerable from the vulnerable endpoints. Exploitation targets the credential-lookup logic behind GET /api/v1/openai-assistants and /:id, POST /api/v1/openai-assistants-file/upload/, DELETE /api/v1/assistants/:id (reached by first importing a poisoned assistant row via POST /api/v1/export-import/import), and GET /api/v1/text-to-speech/voices. It applies to default multi-workspace deployments configured with OpenAI or ElevenLabs credentials; single-workspace instances have no cross-tenant boundary to violate. No user interaction from a victim is required (UI:N).

This is a genuine but moderate-priority cross-tenant access-control flaw, not a headline emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N, 7.6) correctly reflects a network-reachable, authenticated (PR:L) issue that carries an attack requirement (AT:P) - the attacker must know or obtain a valid credential UUID belonging to another workspace, which is the single biggest limiting factor since UUIDs are not enumerable. There is no EPSS score, no CISA KEV listing, and no public exploit code in the provided data, so exploitation status is 'no public exploit identified at time of analysis' - this is not confirmed active exploitation. The VI:H (high integrity) impact appears generous: only the deleteAssistant path enables modification (deleting an assistant, reachable indirectly via a poisoned import), while most impact is confidentiality/abuse of another workspace's OpenAI or ElevenLabs API key. The CWE-639 classification (IDOR / authorization) is accurate, but the 'Authentication Bypass' tag is a mislabel - the attacker is already authenticated and the flaw is a missing workspace-scoping authorization check, not an authentication bypass. Net: real cross-workspace data/credential-abuse risk for multi-tenant Flowise deployments, tempered by the need for valid authentication and knowledge of a foreign credential UUID, and no patch was available at publication.

An authenticated low-privilege user in one Flowise workspace calls an OpenAI-assistant, file-upload, or text-to-speech endpoint and supplies a credential UUID belonging to a different workspace; because the lookup does findOneBy({id}) with no workspaceId filter, the server decrypts and uses the victim workspace's OpenAI or ElevenLabs API key on the attacker's behalf (consuming quota, exfiltrating results, or deleting assistants via a poisoned import). No public exploit code is identified at time of analysis, and success depends on the attacker obtaining a valid foreign credential UUID.