GHSA-5h9v-837x-m97r FlowiseAI: Dataset create+update mass-assignment allows cross-workspace dataset takeover

• npm flowise: < 3.1.2 → fixed in 3.1.2

Summary Type: Mass assignment via `Object.assign(entity, body)` -> client-controlled `workspaceId` (and on create, `id`) overwritten on the Dataset entity -> cross-workspace data takeover and IDOR. File: `packages/server/src/services/dataset/index.ts` Root cause: The Dataset controller/service constructs a `new Dataset()` and copies the request body into it via `Object.assign(...)` without an explicit field allowlist. The request body therefore can include `workspaceId`, `id`, `createdDate`, `updatedDate`. The server only rebinds *some* of these after the assign (e.g. on create, it overwrites `workspaceId` but not `id`; on update, it overwrites `id` but not `workspaceId`). The remaining client-controlled values land directly on the persisted row, breaking workspace isolation. Same root pattern as the dataset entity's sibling controllers and as `DocumentStore` before it was patched in commit 840d2ae. Affected Code File: `packages/server/src/services/dataset/index.ts` ```ts // create (line 203) and update (line 226) Object.assign(newDataset, body) // ` (or equivalent endpoint) with a JSON body that includes `"workspaceId": ""` (an arbitrary other workspace's UUID). State at this point: the request reaches the controller as a workspace-A authenticated request. 4. The controller calls `Object.assign(updateEntity, body)`. The body's `workspaceId` overwrites the entity's `workspaceId` field. The persistence layer commits the row. 5. Final state: the dataset row is now owned by workspace B. Workspace B members can see it, modify it, and use it. Workspace A loses access (it no longer satisfies their workspace filter). The original creator's workspace audit shows nothing because the operation looked like a normal update. Security Impact Severity: High. Cross-workspace boundary violation by any authenticated workspace member. Attacker capability: Any authenticated user with permission to update a dataset can move it to any workspace whose UUID they can guess or enumerate (workspace UUIDs are exposed in many API responses, so enumeration is trivial). Datasets hold training / evaluation data scoped to a workspace. Moving a Dataset across workspaces via `workspaceId` overwrite exposes the dataset (rows, schema, references) to the destination workspace. Preconditions: Authenticated session with edit permission for the source dataset. No second factor required. Workspace UUIDs are exposed via the `/api/v1/workspaces` listing or via any cross-referenced object's `workspaceId` field, so target enumeration is trivial. Differential: PoC-verified by source inspection of the original GHSA-q4pr-4r26-c69r. Patched build (with the suggested fix below) refuses the `workspaceId` field; vulnerable build accepts it and persists it. Suggested Fix Already fixed in PR https://github.com/FlowiseAI/Flowise/pull/6051 (allowlist pattern applied). ```ts // Allowlist pattern (matches commit 840d2ae for DocumentStore): const updatedDataset = new Dataset() if (body. !== undefined) updatedDataset. = body. if (body. !== undefined) updatedDataset. = body. // ...whitelist only the documented fields. Never copy id, workspaceId, createdDate, updatedDate from the client. ``` Regression tests should assert that a request body containing `workspaceId`, `id`, `createdDate`, or `updatedDate` is rejected (or at minimum: does not change those columns on the persisted row) for both create and update paths.