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

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:

@PrimaryGeneratedColumn('uuid')
id: string

The create logic is implemented as:

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:

{
  "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