Vulnerability Database

353,823

Total vulnerabilities in the database

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

Improper Access Control

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

  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:
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.

  • Published: Apr 17, 2026
  • Updated: Apr 18, 2026
  • GHSA: GHSA-3prp-9gf7-4rxx
  • Severity: High
  • Exploit:
  • CISA KEV:

No technical information available.

CWEs:

OWASP TOP 10:

Software From Fixed in
Node.js icon flowise - 3.1.0

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.