Description

Flowise through 3.1.4 contains an insecure direct object reference vulnerability in the OpenAI Assistants integration that allows authenticated attackers to access credentials belonging to other workspaces by supplying an arbitrary credential UUID to Assistants endpoints without workspace ownership verification. Attackers can enumerate cross-workspace assistant metadata, retrieve file and vector store listings, and upload files into victim workspaces by exploiting the missing workspace-scoped authorization check in the credential lookup logic.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-06T22:18:22.873Z",
  "pubdate": "2026-08-06T22:18:22.873Z",
  "executiveSummary": "An Insecure Direct Object Reference (IDOR) vulnerability exists in Flowise through 3.1.4 within the OpenAI Assistants integration.\nThe vulnerability allows authenticated attackers to access credentials belonging to other workspaces by supplying an arbitrary credential UUID to Assistants endpoints.\nThe core issue stems from a lack of proper workspace ownership verification during the credential lookup logic.\nImpact includes the ability for attackers to enumerate cross-workspace assistant metadata, retrieve file and vector store listings, and upload files directly into victim workspaces.\nRisk implications are high for multi-tenant or multi-workspace deployments where strict tenant isolation is required, as unauthorized entities can interact with foreign resources.\nExploitation requires authentication within the application and the ability to supply arbitrary credential UUIDs to vulnerable API endpoints.\nNo additional complex prerequisites are necessary beyond standard authenticated access to exploit the missing authorization checks.",
  "technicalDetails": "The vulnerability is classified as an Insecure Direct Object Reference (IDOR) occurring within the OpenAI Assistants integration components of Flowise through 3.1.4.\nThe root cause of the vulnerability is the complete absence of workspace-scoped authorization checks within the application's credential lookup and validation logic.\nWhen requests are processed by the affected Assistants endpoints, the backend logic accepts a credential UUID supplied directly by the client without verifying whether the authenticated user or their current session context holds ownership of the specified workspace associated with that credential.\nAttackers can leverage this flaw by executing a step-by-step attack flow: first, identifying or guessing arbitrary credential UUIDs, and second, issuing crafted requests containing these foreign UUIDs to the OpenAI Assistants integration endpoints.\nBecause the backend performs database lookups or internal calls using the supplied UUID without enforcing workspace isolation boundaries, the application processes the request using the unauthorized credentials.\nPost-exploitation capabilities resulting from this behavior include the enumeration of cross-workspace assistant metadata, the retrieval of sensitive file and vector store listings belonging to isolated tenants, and the unauthorized uploading of files into victim workspaces.\nThe vulnerable components are exposed via network-accessible API endpoints handling OpenAI Assistants integrations.\nExploitation requires valid user authentication to establish an initial session, but does not require elevated administrative privileges within the targeted foreign workspace, relying entirely on horizontal privilege abuse across workspace boundaries."
}