Description

Flowise before 3.1.4 fails to scope enterprise organization and workspace membership APIs to the caller's tenant, allowing authenticated users to supply arbitrary organization IDs. Attackers can add themselves as organization owners, create workspaces, and gain administrative access to victim organizations by exploiting insufficient tenant isolation in the organizationuser and workspace endpoints.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-15T16:17:43.743Z",
  "pubdate": "2026-09-15T16:17:43.743Z",
  "executiveSummary": "The vulnerability in Flowise prior to version 3.1.4 is a critical Insecure Direct Object Reference (IDOR) / Broken Access Control flaw originating from insufficient tenant isolation within enterprise organization and workspace management APIs. The vulnerability allows authenticated users to bypass organizational security boundaries by manipulating identifiers in API requests, effectively enabling unauthorized cross-tenant access.\nThis flaw impacts Flowise enterprise-grade deployment configurations where multi-tenancy and workspace segmentation are required. By providing arbitrary organization IDs, an attacker can manipulate their membership status, promote themselves to administrative roles, and interact with unauthorized workspaces. The risk implications are severe, as this grants unauthorized users full control over sensitive workflows, data, and configurations belonging to victim organizations. Exploitation requires the attacker to be an authenticated user within the application, but it does not require prior administrative privileges, significantly lowering the barrier for internal or external actors with standard user credentials to escalate their privileges across organizational boundaries.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper implementation of authorization checks within the Flowise backend's organizationuser and workspace API endpoints. The application fails to cryptographically verify or programmatically scope the requested organization or workspace resources against the currently authenticated user's session token or authorized tenant context. Consequently, the backend trustfully processes parameters provided in the request body or URL without ensuring that the caller maintains valid membership or administrative standing within the target organization.\nThe exploitation flow proceeds as follows: First, the attacker identifies a target organization ID (or performs brute-force/enumeration of valid IDs). Second, the attacker crafts a malicious POST or PUT request to the organizationuser endpoint, injecting the target organization's ID into the parameter list. Third, the API controller fails to perform a cross-check between the authenticated user's scope and the target ID, permitting the attacker to perform operations such as creating new workspaces or modifying user roles. By targeting the organizationuser endpoint, an attacker can explicitly add their own user account to the victim organization with elevated 'Owner' permissions.\nOnce administrative access is successfully acquired via this privilege escalation technique, the attacker gains full control over the target organization's workspace management. This includes the ability to create, delete, or modify workflows, access secret configurations, and manipulate system-wide settings associated with the compromised organization. Because the backend logic trusts the user-supplied identifiers, the application treats these requests as legitimate administrative actions performed by a valid member of the target tenant.\nThis vulnerability affects Flowise versions prior to 3.1.4. The exploitation is facilitated by the lack of server-side validation of session-to-resource ownership. The primary concern is the total subversion of the multi-tenancy model, as the API surfaces act as a conduit for lateral movement between disparate organizational environments. The absence of strict scoping at the controller level renders the system unable to enforce tenant boundaries, allowing a malicious actor to maintain persistent unauthorized access to high-privilege resources until the breach is detected and access is manually revoked."
}