Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.8",
  "pubDate": "2026-09-26T14:16:41.297Z",
  "pubdate": "2026-09-26T14:16:41.297Z",
  "executiveSummary": "A critical Broken Access Control (BAC) vulnerability exists in Flowise and flowise-components through version 3.1.4, enabling unauthorized cross-workspace credential access.\nThe vulnerability stems from improper input validation during credential lookups, where the application retrieves credentials by ID without enforcing workspace scoping. This failure allows an authenticated attacker to access and utilize credentials—specifically API keys for OpenAI and ElevenLabs—that belong to other workspaces within the same instance.\nThe impact includes unauthorized use of third-party API services at the expense of other tenants, potential data exposure via those APIs, and the ability to perform actions on behalf of other workspace administrators.\nThis vulnerability requires an attacker to be authenticated to the target Flowise instance; however, they do not require administrative privileges over the victim's workspace. Exploitation is facilitated by the server decrypting and providing API keys to the requesting user based solely on a known or guessed credential UUID, bypassing tenant isolation boundaries.\nGiven the nature of the flaw, which involves the server-side processing of cross-workspace requests, this represents a significant risk to multi-tenant Flowise deployments.",
  "technicalDetails": "The root cause of this vulnerability is an insecure implementation of database queries when fetching sensitive credential objects. Specifically, the application utilizes a lookup mechanism, identified as findOneBy({ id: credentialId }), which strictly filters by the unique identifier without incorporating a mandatory workspaceId constraint.\nThis flaw is present across multiple critical code paths within Flowise, including: 'getAllOpenaiAssistants' and 'getSingleOpenaiAssistant' (invoked via GET /api/v1/openai-assistants and GET /api/v1/openai-assistants/:id), 'uploadFilesToAssistant' (POST /api/v1/openai-assistants-file/upload/), 'deleteAssistant' (DELETE /api/v1/assistants/:id), and the shared helper utility utilized by 'getVoices' (GET /api/v1/text-to-speech/voices).\nThe attack flow commences with an authenticated attacker gaining access to their own Flowise workspace. By identifying the UUID of a credential belonging to a different workspace, the attacker can submit a crafted request to any of the aforementioned endpoints. Because the backend logic lacks workspace-level validation, the server retrieves the target credential, decrypts it, and utilizes it to authenticate requests to external services like OpenAI or ElevenLabs.\nIn the context of 'deleteAssistant', the attack can be chained by first using the 'POST /api/v1/export-import/import' functionality to inject a poisoned assistant row, which may facilitate the unauthorized deletion of assistant configurations in foreign workspaces. The vulnerability effectively nullifies the logical separation between tenants in a multi-tenant environment, allowing any authenticated user to hijack API keys stored within the system's credential manager.\nThe vulnerability resides in the core credential management layer of the Flowise application. Because the application logic relies on implicit trust in the credential ID provided by the client, it fails to verify that the requesting user's session token is authorized to access the workspace associated with the target credential. This results in an Insecure Direct Object Reference (IDOR) pattern on a global scale relative to the application's credential store, providing an attacker with elevated capabilities to perform unauthorized operations using compromised keys."
}