Description

Flowise before 3.1.4 fails to enforce workspace-level authorization checks in openai-realtime endpoints, allowing authenticated users to access tools from ChatFlows in other workspaces by supplying an unscoped chatflowid. Attackers can invoke GET and POST requests to retrieve tool definitions and execute tools from victim workspaces, triggering external side effects and accessing sensitive tool outputs.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-15T16:17:44.170Z",
  "pubdate": "2026-09-15T16:17:44.170Z",
  "executiveSummary": "A critical authorization flaw exists in Flowise versions prior to 3.1.4, specifically within the openai-realtime endpoints. The vulnerability stems from an improper implementation of workspace-level access control, which fails to validate if an authenticated user possesses the appropriate permissions to interact with specific ChatFlows. This breakdown in security boundaries allows an authenticated attacker to perform unauthorized cross-workspace operations.\nBy manipulating the chatflowid parameter, an attacker can bypass intended isolation mechanisms to retrieve sensitive tool definitions and execute arbitrary tools residing in victim workspaces. This exposure leads to unauthorized side effects, potential data exfiltration through tool outputs, and the compromise of sensitive workflows managed within the platform. The risk is significant as it permits lateral movement across tenant boundaries within a multi-tenant environment. Exploitation requires an active authenticated session, but does not necessitate elevated administrative privileges, making it a viable vector for any user with standard platform access.",
  "technicalDetails": "The vulnerability resides in the request handling logic for openai-realtime endpoints in Flowise versions before 3.1.4. The root cause is a failure to implement robust server-side workspace scoping during the validation phase of API requests. When an endpoint receives a request referencing a chatflowid, the application backend fails to perform a cross-reference check between the authenticated user's assigned workspace and the workspace owning the requested chatflowid.\nExploitation follows a predictable sequence: First, an attacker identifies or guesses the chatflowid of a target ChatFlow located in a different workspace. Given the lack of server-side authorization enforcement, the application treats the supplied identifier as trusted. An attacker can then issue a GET request to the openai-realtime endpoint, which returns detailed tool definitions associated with the targeted ChatFlow, effectively leaking internal configuration details and sensitive tool metadata.\nBeyond information disclosure, the vulnerability allows for the execution of tools. By sending a malicious POST request to the affected endpoint, the attacker can trigger tool execution within the context of the victim's workspace. Because the tools are executed without the authorization constraints that should govern workspace isolation, the server proceeds to process the request as if it were a legitimate internal call. This results in the invocation of external services, potential data modification, and the retrieval of sensitive tool outputs that the attacker is not entitled to access.\nThe attack is facilitated by the underlying design of the openai-realtime module, which prioritizes the functional execution of LLM-integrated workflows over the strict enforcement of multi-tenancy access control lists (ACLs). This architectural oversight allows the application to resolve and instantiate tools based solely on the provided ID without verifying that the caller's session context matches the resource owner's context. The impact is a total loss of confidentiality and integrity regarding workspace-specific tool execution, enabling attackers to perform unauthorized actions or exfiltrate sensitive data from workflows they do not own or manage."
}