CVE-2026-41277: Flowise Mass Assignment Vulnerability
HIGHCVE-2026-41277 is a HIGH (CVSS 8.8) mass assignment vulnerability (CWE-284: Improper Access Control) affecting Flowise libraries in the npm ecosystem. The issue involves mass assignment in documentstore create endpoint leads to cross-workspace object takeover (idor). Remediation is available by upgrading affected packages to version 3.1.0.
CVE-2026-41277 at a Glance
Security Impact
CVSS: 8.8
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
How to Fix CVE-2026-41277
To remediate this vulnerability, upgrade all affected Flowise dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
npm install flowise@3.1.0
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
npm ls flowise
How to Check if You Are Affected
To determine whether your Node.js application is affected by CVE-2026-41277, inspect your project dependencies using npm:
npm ls flowise
Analyze the terminal output to locate any version of Flowise in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.1.0), your application is affected.
Note: The npm ls flowise command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-284: Improper Access Control, where the product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. In Flowise, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-41277 Affected Flowise Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
flowise
|
npm |
< 3.1.0
|
3.1.0
|
References
Frequently Asked Questions
What is CVE-2026-41277?
Which Flowise versions are affected?
What version fixes CVE-2026-41277?
Is flowise affected?
What is the CVSS score of CVE-2026-41277?
What CWE is associated with CVE-2026-41277?
How can I check npm dependencies for CVE-2026-41277?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-3prp-9gf7-4rxx",
"modified" : "2026-04-24T21:01:04Z",
"published" : "2026-04-17T21:34:16Z",
"aliases" : [ "CVE-2026-41277" ],
"summary" : "Flowise: Mass Assignment in DocumentStore Create Endpoint Leads to Cross-Workspace Object Takeover (IDOR)",
"details" : "### Summary\nA Mass Assignment vulnerability in the DocumentStore creation endpoint allows authenticated users to control the primary key (id) and internal state fields of DocumentStore entities.\n\nBecause 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.\n\nIn 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.\n\n### Details\nThe DocumentStore entity defines a globally unique primary key:\n\n```typescript\n@PrimaryGeneratedColumn('uuid')\nid: string\n```\n\nThe create logic is implemented as:\n```typescript\nconst documentStore = repo.create(newDocumentStore)\nconst dbResponse = await repo.save(documentStore)\n```\n\nHere is no DTO allowlist or field filtering before persistence. The entire request body is mapped directly to the entity.\nTypeORM save() behavior:\n\n1. If the primary key (id) exists → UPDATE\n2. If not → INSERT\n\nBecause id is accepted from the client, the create endpoint effectively functions as an UPSERT endpoint.\n\nThis allows an authenticated user to submit:\n\n```json\n{\n \"id\": \"<existing_store_id>\",\n \"name\": \"modified\",\n \"description\": \"modified\",\n \"status\": \"SYNC\",\n \"embeddingConfig\": \"...\",\n \"vectorStoreConfig\": \"...\",\n \"recordManagerConfig\": \"...\"\n}\n```\nIf a DocumentStore with the supplied id already exists, save() performs an UPDATE rather than creating a new record.\n\nImportantly:\n\nThe primary key is globally unique (uuid)\nIt is not composite with workspaceId\nThe create path does not enforce ownership validation before calling save()\nThis introduces a broken object-level authorization risk.\n\nIf an attacker can obtain or enumerate a valid DocumentStore UUID belonging to another workspace, they can:\nSubmit a POST create request with that UUID.\nTrigger an UPDATE on the existing record.\nPotentially overwrite fields including workspaceId, effectively reassigning the object to their own workspace.\n\nBecause 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.\n\nAdditionally, 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.\n\n### PoC\n\n1. Create a normal DocumentStore in Workspace A.\n2. Capture its id from the API response.\n3. From Workspace B (or another authenticated context), submit:\n\n```http\nPOST /api/v1/document-store\nContent-Type: application/json\n\n{\n \"id\": \"<id_from_workspace_A>\",\n \"name\": \"hijacked\",\n \"description\": \"hijacked\"\n}\n```\n\nBecause the service uses repository.save() with a client-supplied primary key:\n\n- The existing record is updated.\n- The object may become reassigned depending on how workspaceId is handled at controller level.\n- If workspaceId is overwritten during the create flow, the store is effectively migrated to the attacker’s workspace.\n- This demonstrates object takeover via UPSERT semantics on a create endpoint.\n\n### Impact\nThis vulnerability enables:\n\n- Mass Assignment on server-managed fields\n- Overwrite of existing objects via implicit UPSERT behavior\n- Broken Object Level Authorization (BOLA)\n- Potential cross-workspace object takeover in multi-tenant deployments\n- 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.\n\nBecause DocumentStore objects control embedding providers, vector store configuration, and record management logic, successful takeover can affect data indexing, retrieval, and AI workflow execution.\n\nThis represents a high-risk authorization flaw in multi-tenant environments.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
}, {
"type" : "CVSS_V4",
"score" : "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "npm",
"name" : "flowise"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "3.1.0"
} ]
} ],
"database_specific" : {
"last_known_affected_version_range" : "<= 3.0.13"
}
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-3prp-9gf7-4rxx"
}, {
"type" : "ADVISORY",
"url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-41277"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/FlowiseAI/Flowise"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-284", "CWE-639", "CWE-915" ],
"severity" : "HIGH",
"github_reviewed" : true,
"github_reviewed_at" : "2026-04-17T21:34:16Z",
"nvd_published_at" : "2026-04-23T20:16:16Z"
}
}