A high-severity vulnerability (CVE-2026-41277) has been disclosed in Flowise, the popular open-source drag-and-drop LLM workflow builder, allowing authenticated attackers to hijack DocumentStore objects belonging to other tenants via a broken object-level authorization flaw rooted in improper mass assignment.
Flowise is a widely adopted, open-source drag-and-drop UI platform used by developers and enterprises to build customized Large Language Model (LLM) pipelines and AI workflows.
Its DocumentStore feature manages critical backend components, including embedding providers, vector store configuration, and record management logic, making any successful takeover of these objects a direct threat to AI workflow integrity, data indexing, and retrieval operations.
Published under advisory GHSA-3prp-9gf7-4rxx, this vulnerability affects all Flowise versions up to and including 3.0.13, and has been patched in the 3.1.0 release. With a CVSS v4 score of 7.6 (High), the flaw poses a significant risk for any organization running Flowise in a multi-tenant or multi-workspace SaaS environment.
Flowise CVE-2026-41277: IDOR Vulnerability
The vulnerability exists in the POST /api/v1/document-store endpoint, where the DocumentStore entity is created. The core issue is that the service accepts the entire request body and maps it directly to the entity without any Data Transfer Object (DTO) allowlist or field filtering before persistence.
The vulnerable code pattern in Flowise follows this logic:
typescriptconst documentStore = repo.create(newDocumentStore)
const dbResponse = await repo.save(documentStore)DocumentStore entity defines a globally unique primary key using TypeORM’s @PrimaryGeneratedColumn('uuid') decorator. Because TypeORM’s save() method performs an UPDATE when the provided id already exists in the database, and an INSERT when it does not, this endpoint effectively operates as an implicit UPSERT rather than a strict create operation.
Since no ownership validation is enforced before save() is called, any authenticated user can supply an existing id item from another workspace and trigger a silent overwrite.
IDOR via UPSERT Semantics
The attack chain is straightforward and low-complexity, requiring only low privileges and no user interaction, as reflected by the CVSS:4.0 vector AV:N/AC:L/AT:P/PR:L/UI:N.
An attacker proceeds through the following steps:
- Create a legitimate DocumentStore in Workspace A and capture its UUID from the API response.
- Switch context to Workspace B (another authenticated tenant session).
- Submit a crafted
POST /api/v1/document-storerequest with the captured UUID as theidfield and adversary-controlled values forname,description,status,embeddingConfig,vectorStoreConfig, andrecordManagerConfig. - Trigger the UPSERT because the UUID exists in the database, TypeORM’s
save()silently performs an UPDATE that overwrites the original record. - Reassign the object if
workspaceIdis overwritten in the create flow, the store is effectively migrated to the attacker’s workspace, completing a full cross-workspace object takeover.
This is a textbook Broken Object Level Authorization (BOLA/IDOR) flaw; the server never verifies that the record being updated belongs to the requester’s workspace before persisting the changes.
This vulnerability is classified under three distinct weaknesses:
- CWE-284 (Improper Access Control) – the endpoint fails to restrict unauthorized actors from modifying resources.
- CWE-639 (Authorization Bypass Through User-Controlled Key) – client-supplied primary keys bypass authorization logic.
- CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes) – the full request body is mapped to the entity without field-level filtering.
The CVSS v4 impact scores indicate High Confidentiality and High Integrity impacts on the vulnerable system, with Low Availability.
In production SaaS environments, successful exploitation allows attackers to: overwrite AI pipeline configurations belonging to other tenants, disrupt vector store and embedding workflows, potentially exfiltrate sensitive retrieval logic, and escalate unauthorized access across workspace boundaries.
Remediation
The vulnerability is fully addressed in Flowise version 3.1.0. Organizations running any version ≤ 3.0.13 should treat this as an urgent upgrade priority, especially those operating in multi-tenant or shared-workspace deployments.
Beyond patching, security teams should implement the following defensive measures:
- Enforce DTO allowlists that explicitly define which fields are accepted by the create endpoint, stripping server-managed fields like
idandworkspaceIdfrom client input. - Validate record ownership before any
save()operation by scoping queries with bothidandworkspaceIdto enforce workspace-level authorization. - Audit all service functions that retrieve DocumentStore entities by
idalone to ensure consistentworkspaceIdscoping across the codebase. - Implement API-level input validation middleware to reject requests that supply server-managed primary keys on create endpoints.
- Enable access logging on document store API endpoints to detect anomalous UPSERT patterns indicative of exploitation attempts.
Flowise has recently faced a series of authorization-related vulnerabilities, including a separate header-spoofing privilege escalation (CVE-2026-30820) patched in version 3.0.13, and a critical SSRF bypass affecting multiple tool integrations. This pattern suggests a broader need for a comprehensive security review of the platform’s authorization architecture.
FAQ
Q1: What is CVE-2026-41277?
A high-severity mass assignment vulnerability in Flowise ≤ 3.0.13 that allows authenticated users to overwrite DocumentStore objects in other workspaces via a UPSERT flaw.
Q2: Who is affected by this vulnerability?
Any organization running Flowise in a multi-tenant or multi-workspace deployment on versions up to and including 3.0.13 is at risk.
Q3: How can I fix the Flowise IDOR vulnerability?
Immediately upgrade to Flowise version 3.1.0, which contains the official patch resolving the mass assignment and broken authorization issues.
Q4: What damage can an attacker cause by exploiting GHSA-3prp-9gf7-4rxx?
An attacker can hijack, modify, or reassign AI workflow configurations, vector stores, and embedding settings belonging to other tenants.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
