CVE-2026-41277

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.

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.

CVE-2026-41277 has a CVSS score of 8.8 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.1.0); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-41277? CVE-2026-41277 is a high-severity security vulnerability in flowise (npm), affecting versions <= 3.0.13. It is fixed in 3.1.0.
2. How severe is CVE-2026-41277? CVE-2026-41277 has a CVSS score of 8.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of flowise are affected by CVE-2026-41277? flowise (npm) versions <= 3.0.13 is affected.
4. Is there a fix for CVE-2026-41277? Yes. CVE-2026-41277 is fixed in 3.1.0. Upgrade to this version or later.
5. Is CVE-2026-41277 exploitable, and should I be worried? Whether CVE-2026-41277 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-41277 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-41277? Upgrade flowise to 3.1.0 or later.