# CVE-2026-46478: flowise — Fixed in 3.1.2

📦 npm

Not in CISA KEV

# CVE-2026-46478 — flowise

[Fix: FlowiseAI/Flowise#6051](https://github.com/FlowiseAI/Flowise/pull/6051)

CVE-2026-46478 is a CWE-915 vulnerability in flowise. A fix is available for flowise — see the affected versions and patch details below.

Flowise: DatasetRow create+update mass-assignment allows cross-workspace row takeover

Also known as[GHSA-7j65-65cr-6644](/vulnerability/GHSA-7j65-65cr-6644)

Published

Jun 8, 2026

Updated

Oct 28, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

## Exploitation Status

### No confirmed exploitation observed yet

-   CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
-   A successful exploit gives an attacker total control of the affected component, not partial access.
-   CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-46478.

## EPSS Exploitation Probability

[via FIRST.org ↗](https://www.first.org/epss/)

0.3%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs28th percentile — riskier than 28% of all scored CVEsHighest risk

0.00%0.35%0.71%1.06%0.3%0.3%Jul 26Oct 26Nov 26

Probability of exploitation in the next 30 days, from [FIRST.org EPSS](https://www.first.org/epss/).

## Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

0other npm packages depend on this — each one inherits the vulnerability until it's patched upstream

`flowise`npm

10Kdownloads / week

## Description

### Summary

**Type:** Mass assignment via `Object.assign(entity, body)` -> client-controlled `workspaceId` (and on create, `id`) overwritten on the DatasetRow entity -> cross-workspace data takeover and IDOR. **File:** `packages/server/src/services/dataset/index.ts` **Root cause:** The DatasetRow controller/service constructs a `new DatasetRow()` 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 datasetrow entity's sibling controllers and as `DocumentStore` before it was patched in commit 840d2ae.

### Affected Code

**File:** `packages/server/src/services/dataset/index.ts`

```
// create (line 274) and update (line 315)
Object.assign(newRow, rowBody)          // <-- BUG: rowBody.id, rowBody.datasetId accepted
```

**Why it's wrong:** `Object.assign(target, source)` copies every own enumerable property of `source` onto `target`. The TypeORM/SQL persistence layer below it does not strip ownership-bearing columns, so `workspaceId` set in the request body lands as the new `workspaceId` of the persisted row. The DocumentStore patch (commit 840d2ae) demonstrated the intended fix shape (explicit field-by-field allowlist) but it has not been applied to this entity.

### Exploit Chain

1.  Attacker is an authenticated member of workspace A. They have a session cookie / JWT for the Flowise web UI. State at this point: attacker can read and write entities scoped to workspace A.
2.  Attacker creates a datasetrow in workspace A via the documented API (or reuses an existing one they own). They note its entity `id`.
3.  Attacker issues a `PUT /api/v1/datasetrows/<id>` (or equivalent endpoint) with a JSON body that includes `"workspaceId": "<workspace-B-id>"` (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 datasetrow 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 datasetrow 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). DatasetRows hold individual training/evaluation records. The mass assignment lets a member rebind a row to a Dataset in another workspace via `datasetId`, exposing the row content to the destination workspace. **Preconditions:** Authenticated session with edit permission for the source datasetrow. 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](https://github.com/FlowiseAI/Flowise/pull/6051) (allowlist pattern applied).

```
// Allowlist pattern (matches commit 840d2ae for DocumentStore):
const updatedDatasetRow = new DatasetRow()
if (body.<allowed_field_1> !== undefined) updatedDatasetRow.<allowed_field_1> = body.<allowed_field_1>
if (body.<allowed_field_2> !== undefined) updatedDatasetRow.<allowed_field_2> = body.<allowed_field_2>
// ...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.

## Affected Packages

1 total 1 fixed

Ecosystem

Package

Vulnerable range

Fix

📦npm

`flowise` 

all versions

3.1.2`npm install flowise@3.1.2`

## Affected Products

1 product · 1 configurations

Application

`flowise`flowiseai

< 3.1.2

range

## Detection & mitigation playbook

Open-source dependency

1.  ### Detect
    
    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for flowise, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
    
2.  ### Fix
    
    Update flowise to 3.1.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-46478 is resolved across your whole dependency graph.
    
3.  ### Workarounds
    
    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
    

## Frequently Asked Questions

\## Summary \*\*Type:\*\* Mass assignment via \`Object.assign(entity, body)\` -> client-controlled \`workspaceId\` (and on create, \`id\`) overwritten on the DatasetRow entity -> cross-workspace data takeover and IDOR. \*\*File:\*\* \`packages/server/src/services/dataset/index.ts\` \*\*Root cause:\*\* The DatasetRow controller/service constructs a \`new DatasetRow()\` 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.

O3 Security · Impact-Aware SCA

### Is CVE-2026-46478 in your dependencies?

Find it across npm, including transitive dependencies.

[Scan my dependencies](/book-demo) [How O3 SCA works](/impact-aware-sca)