GHSA-C2C9-MFW7-P8HW: Cross-Workspace Chatflow Disclosure in Flowise

Flowise is an open-source low-code platform for building custom Large Language Model (LLM) applications. It supports multi-tenant environments through workspaces, utilizing API keys to segment access and execution rights. This architecture is designed to isolate chatflows and prevent cross-tenant data exposure.

GHSA-C2C9-MFW7-P8HW represents an Incorrect Authorization vulnerability (CWE-863) within this multi-tenant isolation mechanism. The flaw specifically affects the /api/v1/chatflows/apikey/:apikey endpoint, which client applications use to retrieve necessary configuration data for specific chat components.

In versions prior to 3.1.2, this endpoint fails to enforce strict workspace boundaries. An authenticated user belonging to one workspace can exploit this endpoint to disclose chatflow designs across the entire Flowise instance, provided those chatflows do not have explicit individual passwords configured.

The vulnerability stems from missing database query scoping. When a client application makes a request to the affected endpoint, it supplies an API key in the URL path. The Flowise backend receives this key and validates its format and active status.

However, the authorization check terminates prematurely. While the backend confirms the API key is active, it fails to extract the workspaceId associated with that specific key to use in the subsequent data retrieval phase. The resulting database query constructs a search for chatflows using only the "unprotected" status as the primary filter condition.

Because the workspaceId is omitted from the WHERE clause of the database query, the execution engine returns every unprotected chatflow present in the instance. The system then serializes this unrestricted result set and returns it to the client, effectively bypassing the intended multi-tenant authorization logic.

Exploitation of this vulnerability requires network access to the target Flowise instance and possession of at least one valid API key. This key can belong to a low-privileged workspace, making this an attack vector for lateral data discovery within shared development or production environments.

The attacker crafts an HTTP GET request directed at the vulnerable endpoint, substituting the :apikey parameter with their legitimate key. The request requires no complex payloads, special headers, or specific instance misconfigurations to execute successfully.

curl -X GET "https://flowise.example.com/api/v1/chatflows/apikey/sk-attacker-valid-key" \
     -H "Accept: application/json"

The resulting JSON response contains an array of chatflow objects. These objects include full structural details, node configurations, and prompt templates for applications belonging to entirely separate, unrelated workspaces.

The following sequence illustrates how the logic flaw causes data leakage across tenant boundaries.

The primary impact is unauthorized information disclosure affecting the confidentiality of AI agent designs. While the vulnerability is read-only and does not permit modification or deletion of resources, the leaked data often contains highly sensitive intellectual property.

Exposed chatflows reveal the precise system prompts, retrieval-augmented generation (RAG) configurations, and logic pathways designed by other users. This exposes proprietary prompt engineering techniques and internal business logic that application owners intend to keep confidential.

Furthermore, if developers have improperly embedded hardcoded secrets, API keys for external services (like OpenAI, Anthropic, or vector databases), or sensitive metadata directly into their unprotected chatflow nodes, these credentials will be exposed to the attacker, escalating the overall severity of the breach.

Administrators must upgrade all Flowise deployments to version 3.1.2 or later. The patch modifies the backend controller logic to explicitly extract the workspaceId linked to the provided API key and appends it as a mandatory filter parameter in the underlying database query.

If immediate patching is not technically feasible, administrators can temporarily mitigate the risk by configuring network-level access controls or Web Application Firewall (WAF) rules. Restricting access to the /api/v1/chatflows/apikey/ endpoint to trusted internal IP addresses prevents external lateral exploitation.

Additionally, ensuring that all individual chatflows are configured with explicit password protection will prevent them from being returned by the vulnerable query. The flaw specifically targets chatflows that rely solely on workspace boundaries for access control rather than explicit individual protection mechanisms.