Flowise: Mass Assignment in DocumentStore Create Endpoint Leads to Cross-Workspace Object Takeover (IDOR)

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.0, a Mass Assignment vulnerability in the DocumentStore creation endpoint allows authenticated users to control the primary key (id) and internal state fields of DocumentStore entities. Because the service uses repository.save() with a client-supplied primary key, the POST create endpoint behaves as an implicit UPSERT operation. This enables overwriting existing DocumentStore objects. In multi-workspace or multi-tenant deployments, this can lead to cross-workspace object takeover and broken object-level authorization (IDOR), allowing an attacker to reassign or modify DocumentStore objects belonging to other workspaces. This vulnerability is fixed in 3.1.0.

Source published

23 Apr 2026 19:48:57 UTC

Source modified

25 Apr 2026 01:31:29 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · 7.6 CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.0, a Mass Assignment vulnerability in the DocumentStore creation endpoint allows authenticated users to control the primary key (id) and internal state fields of DocumentStore entities. Because the service uses repository.save() with a client-supplied primary key, the POST create endpoint behaves as an implicit UPSERT operation. This enables overwriting existing DocumentStore objects. In multi-workspace or multi-tenant deployments, this can lead to cross-workspace object takeover and broken object-level authorization (IDOR), allowing an attacker to reassign or modify DocumentStore objects belonging to other workspaces. This vulnerability is fixed in 3.1.0.

Source published

Apr 23, 2026, 7:48:57 PM (timezone not stated)

Source modified

Apr 25, 2026, 1:31:29 AM (timezone not stated)

Observed here

28 Oct 2026 05:07:41 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 4.0 · 7.6 CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.0, a Mass Assignment vulnerability in the DocumentStore creation endpoint allows authenticated users to control the primary key (id) and internal state fields of DocumentStore entities. Because the service uses repository.save() with a client-supplied primary key, the POST create endpoint behaves as an implicit UPSERT operation. This enables overwriting existing DocumentStore objects. In multi-workspace or multi-tenant deployments, this can lead to cross-workspace object takeover and broken object-level authorization (IDOR), allowing an attacker to reassign or modify DocumentStore objects belonging to other workspaces. This vulnerability is fixed in 3.1.0.

Source published

23 Apr 2026 20:16:16 UTC

Source modified

26 Oct 2026 21:10:00 UTC

Observed here

27 Oct 2026 10:10:11 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · [email protected] · Secondary · 7.6 CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

CVSS 3.1 · [email protected] · Primary · 8.8 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

### Summary A Mass Assignment vulnerability in the DocumentStore creation endpoint allows authenticated users to control the primary key (id) and internal state fields of DocumentStore entities. Because the service uses repository.save() with a client-supplied primary key, the POST create endpoint behaves as an implicit UPSERT operation. This enables overwriting existing DocumentStore objects. In multi-workspace or multi-tenant deployments, this can lead to cross-workspace object takeover and broken object-level authorization (IDOR), allowing an attacker to reassign or modify DocumentStore objects belonging to other workspaces. ### Details The DocumentStore entity defines a globally unique primary key: ```typescript @PrimaryGeneratedColumn('uuid') id: string ``` The create logic is implemented as: ```typescript const documentStore = repo.create(newDocumentStore) const dbResponse = await repo.save(documentStore) ``` Here is no DTO allowlist or field filtering before persistence. The entire request body is mapped directly to the entity. TypeORM save() behavior: 1. If the primary key (id) exists → UPDATE 2. If not → INSERT Because id is accepted from the client, the create endpoint effectively functions as an UPSERT endpoint. This allows an authenticated user to submit: ```json { "id": "<existing_store_id>", "name": "modified", "description": "modified", "status": "SYNC", "embeddingConfig": "...", "vectorStoreConfig": "...", "recordManagerConfig": "..." } ``` If a DocumentStore with the supplied id already exists, save() performs an UPDATE rather than creating a new record. Importantly: The primary key is globally unique (uuid) It is not composite with workspaceId The create path does not enforce ownership validation before calling save() This introduces a broken object-level authorization risk. If an attacker can obtain or enumerate a valid DocumentStore UUID belonging to another workspace, they can: Submit a POST create request with that UUID. Trigger an UPDATE on the existing record. Potentially overwrite fields including workspaceId, effectively reassigning the object to their own workspace. Because the service layer does not verify that the existing record belongs to the caller’s workspace before updating, this may result in cross-workspace object takeover. Additionally, several service functions retrieve DocumentStore entities by id without consistently scoping by workspaceId, increasing the risk of IDOR if controller-level protections are bypassed or misconfigured. ### PoC 1. Create a normal DocumentStore in Workspace A. 2. Capture its id from the API response. 3. From Workspace B (or another authenticated context), submit: ```http POST /api/v1/document-store Content-Type: application/json { "id": "<id_from_workspace_A>", "name": "hijacked", "description": "hijacked" } ``` Because the service uses repository.save() with a client-supplied primary key: - The existing record is updated. - The object may become reassigned depending on how workspaceId is handled at controller level. - If workspaceId is overwritten during the create flow, the store is effectively migrated to the attacker’s workspace. - This demonstrates object takeover via UPSERT semantics on a create endpoint. ### Impact This vulnerability enables: - Mass Assignment on server-managed fields - Overwrite of existing objects via implicit UPSERT behavior - Broken Object Level Authorization (BOLA) - Potential cross-workspace object takeover in multi-tenant deployments - In a SaaS or shared-workspace environment, an attacker who can obtain or guess a valid UUID may modify or reassign DocumentStore objects belonging to other tenants. Because DocumentStore objects control embedding providers, vector store configuration, and record management logic, successful takeover can affect data indexing, retrieval, and AI workflow execution. This represents a high-risk authorization flaw in multi-tenant environments.

Source published

17 Apr 2026 21:34:16 UTC

Source modified

5 May 2026 16:11:32 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CVSS_V4 · CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N

Publisher rating · HIGH