GHSA-3prp-9gf7-4rxx

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