CVE-2026-100609 in Flowise
Summary
by MITRE • 09/26/2026
Flowise (npm packages `flowise` and `flowise-components`) through 3.1.4 looks up credentials by ID without filtering on the requesting user's workspace (findOneBy({ id: credentialId }) with no workspaceId condition) in several code paths: getAllOpenaiAssistants/getSingleOpenaiAssistant (GET /api/v1/openai-assistants and /api/v1/openai-assistants/:id), uploadFilesToAssistant (POST /api/v1/openai-assistants-file/upload/), deleteAssistant (DELETE /api/v1/assistants/:id, reachable by first importing a poisoned assistant row via POST /api/v1/export-import/import), and the shared helper used by getVoices (GET /api/v1/text-to-speech/voices). An authenticated user of one workspace can supply a credential UUID belonging to another workspace, causing the server to decrypt and use that workspace's OpenAI or ElevenLabs API key on the attacker's behalf. No patched version was available at the time of publication.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Flowise versions through 3.1.4 represents a critical Insecure Direct Object Reference (IDOR) flaw rooted in insufficient authorization checks within the credential management subsystem. The core technical deficiency lies in the database query logic used to retrieve sensitive API credentials, specifically OpenAI and ElevenLabs keys. When an authenticated user requests access to a specific credential by its unique identifier, the application executes a findOneBy operation targeting only the credential ID without verifying that this resource belongs to the requesting user's assigned workspace. This architectural oversight allows any valid session token to bypass multi-tenancy isolation boundaries, effectively treating all credentials as globally accessible within the scope of authenticated API calls rather than restricting them to their respective organizational contexts.
This lack of workspace-level filtering manifests across multiple distinct code paths and HTTP endpoints, creating a broad attack surface for exploitation. The flaw is present in functions such as getAllOpenaiAssistants and getSingleOpenaiAssistant, which are accessible via GET requests to /api/v1/openai-assistants and its individual resource endpoint respectively. Furthermore, the vulnerability extends to file upload operations targeting assistants through POST /api/v1/openai-assistants-file/upload/, assistant deletion processes via DELETE /api/v1/assistants/:id, and even voice retrieval functions accessed through GET /api/v1/text-to-speech/voices. The deleteAssistant endpoint is particularly dangerous because it can be triggered indirectly by importing a maliciously crafted assistant record using the POST /api/v1/export-import/import feature, allowing an attacker to potentially disrupt services or trigger side effects in other workspaces without direct knowledge of their internal IDs if they are enumerated through other means.
The operational impact of this vulnerability is severe, primarily concerning data confidentiality and integrity within multi-tenant deployments. An authenticated user from one workspace can supply a credential UUID belonging to another tenant, causing the server to decrypt and utilize that external organization's API keys for malicious purposes. This enables unauthorized access to third-party services such as OpenAI or ElevenLabs using stolen credentials, leading to potential financial loss through incurred usage charges, intellectual property theft via generated content, and reputational damage if the compromised accounts are used for spamming or generating harmful material. Since no patched version was available at the time of publication, organizations relying on these versions face immediate risk unless manual mitigations are applied.
From a classification perspective, this issue aligns with CWE-639, which describes authorization bypass through direct object reference, and maps to MITRE ATT&CK technique T1078, specifically valid accounts used for lateral movement or privilege escalation within the application's logical boundaries. To mitigate this risk in unpatched environments, administrators should immediately restrict API access by IP if possible, enforce strict network segmentation between Flowise instances serving different tenants, and monitor logs for unusual patterns of credential usage across disparate workspaces. Additionally, implementing a custom middleware layer that validates workspace ownership against the requested resource ID before executing database queries serves as an effective temporary control until official patches are released.