Flowise versions through 3.1.4 have a server-side request forgery (SSRF) vulnerability that allows authenticated users with specific permissions to bypass SSRF protections in the Custom Function sandbox. This bypass is achieved by requiring a module subpath inside an allowlisted package, which evades sandbox checks and returns an unwrapped HTTP client. Exploitation enables attackers to send arbitrary HTTP requests to internal network addresses or cloud metadata endpoints, potentially leading to network mapping, credential disclosure, and unauthorized state changes on internal services.
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.
Flowise before 3.1.4 contains a remote code execution vulnerability in the Custom MCP node that allows authenticated attackers to execute arbitrary code by supplying npx package names in the mcpServerConfig parameter. Attackers can invoke npx with attacker-controlled npm packages to execute code on the Flowise server.
Flowise (packages flowise and flowise-components) in versions <= 3.1.2 contain a sandbox escape in the vm2/@flowiseai/nodevm JavaScript sandbox. An authenticated user with access to the /api/v1/node-custom-function endpoint can escape the sandbox by supplying attacker-controlled executablePath and args parameters to puppeteer.launch(), which internally invokes child_process.spawn() outside the sandbox boundary. This allows execution of arbitrary OS commands as the Flowise process user (root in the official Docker image) and arbitrary host file disclosure via Chromium's file:// URL handling. In versions 3.0.8–3.1.2 exploitation requires ALLOW_BUILTIN_DEP=true; earlier versions are exploitable by default. Fixed in 3.1.3.
Flowise before 3.0.6 contains an arbitrary file access vulnerability due to missing validation that the chatflowId and chatId parameters are UUIDs or numbers in file handling operations. By supplying a path-traversal value (e.g., '../../../../../tmp') as the chatflow id, an unauthenticated attacker can use the /api/v1/chatflows endpoint (via addBase64FilesToStorage) to write arbitrary files, and the /api/v1/get-upload-file and /api/v1/openai-assistants-file/download endpoints (via streamStorageFile) to read arbitrary files. Arbitrary file write may lead to remote code execution.
Flowise versions before 3.1.2 have a mass assignment vulnerability in the PUT /api/v1/user endpoint. Authenticated users can modify the credential field without proper validation, allowing attackers to bypass password change verification and session invalidation. This enables persistent account access even after temporary session compromise. The issue is fixed in version 3.1.2.
Flowise versions prior to 3.0.13 have an information exposure vulnerability in the password reset API endpoint. This flaw allows unauthenticated attackers to retrieve full user objects, including personally identifiable information (PII), by submitting requests with known email addresses. Sensitive data exposed includes user IDs, names, account status, and timestamps. The vulnerability enables attackers to enumerate valid email addresses and harvest user data without authentication.
Flowise versions prior to 3.0.8 contain a cross-site scripting (XSS) vulnerability due to insufficient input filtering in chat messages and custom agent functions. This flaw allows attackers to inject malicious JavaScript, such as iframe payloads, which execute in the victim's browser and can lead to theft of cookies and session data. The vulnerability is fixed in version 3.0.8.
Flowise versions prior to 3.1.0 contain a Server-Side Request Forgery (SSRF) vulnerability in the Execute Flow function. An attacker can supply an intranet address via the base URL field, bypassing internal checks, causing the server to make HTTP requests to internal network addresses. This may allow attackers to enumerate internal services, access sensitive management interfaces, or leak confidential information. A fix is available that involves calling secureFetch for verification.
Flowise 3.0.1 on-premise deployment contains a critical authentication bypass vulnerability due to an unprotected registration endpoint (/api/v1/account/register). An unauthenticated attacker can create new user accounts without restrictions, gaining authenticated access to the Flowise API. This allows bypassing normal authentication controls after the initial organization setup is complete.
Flowise versions prior to 3.0.10 do not invalidate existing active sessions after a user changes their password. This allows an attacker with an active session token or access to a logged-in device to maintain access even after the legitimate user rotates their credentials. The vulnerability undermines the security benefit of password changes by permitting persistent unauthorized access. A fix is available in version 3.0.10.
Flowise v3.0.1 < 3.0.8 and all versions after with 'ALLOW_BUILTIN_DEP' enabled contain an authenticated remote code execution vulnerability and node VM sandbox escape due to insecure use of integrated modules (Puppeteer and Playwright) within the nodevm execution environment. An authenticated attacker able to create or run a tool that leverages Puppeteer/Playwright can specify attacker-controlled browser binary paths and parameters. When the tool executes, the attacker-controlled executable/parameters are run on the host and circumvent the intended nodevm sandbox restrictions, resulting in execution of arbitrary code in the context of the host. This vulnerability was incorrectly assigned as a duplicate CVE-2025-26319 by the developers and should be considered distinct from that identifier.
Flowise versions prior to 3.0.8 contain a vulnerability in the ReadFileTool that allows authenticated users to read arbitrary files on the server filesystem. This occurs because the tool does not restrict file path access, enabling attackers to access sensitive files such as encryption keys and database files. The vulnerability has been confirmed in the latest Flowise Docker image and can lead to remote command execution. A fix is available in version 3.0.8.
Flowise contains a critical vulnerability in its WriteFileTool that allows authenticated users to write arbitrary files to any location on the server's file system. This lack of path restriction can lead to remote command execution by overwriting sensitive files such as SSH authorized keys or system libraries. The vulnerability affects Flowise versions prior to 3.0.8 and has been confirmed in the latest Docker image. A fix is available in version 3.0.8.
Flowise versions from 2.2.7-patch.1 up to but not including 3.0.6 have a critical remote code execution vulnerability via the Custom MCP feature. This feature executes OS commands without sandboxing and the platform lacks strong authentication and role-based access controls by default. An attacker can exploit this to run arbitrary system commands, potentially compromising the entire server or container running Flowise. A fix is available in version 3.0.6.
Flowise versions 3.0.5 up to but not including 3.0.6 contain an arbitrary file read vulnerability in the chatId parameter of two API endpoints. This flaw allows unauthenticated users with knowledge of a valid chatflowId UUID to read arbitrary files on the local filesystem, including the default SQLite database file. The vulnerability arises from insufficient validation of the chatId parameter combined with fallback logic that bypasses directory restrictions. Exploitation can lead to disclosure of sensitive data such as API keys stored in the database and causes denial of service by corrupting file access until server restart.
The Custom MCPs feature is designed to execute OS commands, for instance, using tools like `npx` to spin up local MCP Servers. However, Flowise's inherent authentication and authorization model is minimal and lacks role-based access controls (RBAC). Furthermore, in Flowise versions before 3.0.1 the default installation operates without authentication unless explicitly configured. This combination allows unauthenticated network attackers to execute unsandboxed OS commands.
FlowiseDB versions up to 2.2.7 contain an SQL injection vulnerability in the importChatflows API, exploitable by authenticated users. The vulnerability arises from unsafe construction of SQL queries using user-supplied chatflow IDs without proper validation or sanitization. This allows attackers to inject malicious SQL code, potentially leading to data leakage or manipulation. Additionally, insufficient validation of chatflow IDs can lead to path traversal issues when importing crafted JSON files. The vulnerability has a CVSS score of 5.9 (medium severity).
Flowise versions up to 2.2.7 contain a critical vulnerability allowing attackers to write arbitrary files to the filesystem via the /api/v1/document-store/loader/process API. This is due to improper validation of the fileName parameter, enabling directory traversal and arbitrary file overwrite. Exploitation can lead to remote code execution (RCE), demonstrated by overwriting package.json to modify startup scripts. The vulnerability has a CVSS score of 10.0, indicating critical severity.