CVE-2026-46441 is a mass assignment flaw in the Flowise assistant update endpoint. Authenticated users can change server-controlled fields such as workspaceId and reassign assistants to other workspaces, breaking tenant isolation. The NVD record scores it CVSS 9.6 (critical). It is fixed in Flowise 3.1.2.
What's affected
Flowise versions before 3.1.2 are affected, and the GitHub advisory lists the npm package flowise at 3.1.1 and earlier. The patched version is 3.1.2.
The assistant update endpoint does not restrict which properties a client can set. The record names workspaceId, createdDate and updatedDate. Missing server-side validation and authorization checks allow the change.
The vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N: low privileges are needed, so the attacker is a signed in user, and the scope changes because the effect crosses a workspace boundary. The advisory lists no workarounds.
How to check if you're exposed
- Find your version. For an npm install:
npm ls flowise
- For containers, read the image tag and compare it with 3.1.2.
- Decide whether you run more than one workspace. The advisory frames the impact for multi-workspace environments.
- Review who holds accounts. Any authenticated user counts as a possible source.
- Look at assistants for unexpected workspace membership or odd timestamps.
What to do now
- Upgrade Flowise to 3.1.2 or later.
- After upgrading, audit assistants for ones that sit in the wrong workspace and move them back.
- Review user accounts and remove those that are not needed.
- Do not expose Flowise directly to the internet. Put it behind a VPN or an access proxy.
- If workspaces separate customers or teams with sensitive data, tell the owners and check what the moved assistants could reach.
Why it matters
The class is CWE-915, improperly controlled modification of dynamically determined object attributes. The record also lists CWE-284, improper access control, and CWE-639, authorization bypass through a user-controlled key.
The pattern is common in web APIs. The code accepts a whole object from the client and writes it to the database. If it does not list which fields a client may set, fields meant for the server become writable.
Here, the field is the one that decides which workspace owns a resource. Changing it moves data across a boundary the product promises to enforce. The record's KEV flag is false.
Designing against this class of bug
Mass assignment is cheap to prevent and easy to miss in review. A few habits help in any API you build or run:
- Accept only a named list of fields on update. Anything not on the list is ignored or rejected.
- Never take ownership or tenant fields from the request body. Derive them from the authenticated session.
- Check on every update that the caller owns both the resource being changed and the destination it is being moved to.
- Write tests that send extra fields and assert that they do not change.
For a platform such as Flowise, where assistants, credentials and data sources are tied to a workspace, the workspace field is effectively a security boundary. Treat it that way in your own configuration too: keep sensitive workspaces on separate instances if the isolation matters to you more than convenience.
Try it yourself
Not every critical score has the same practical risk. This demo walks through checking whether a flaw is exploitable in your own setup.
Click through it at your own pace, or open it full screen.
Quick check
Do I need to be logged in to abuse this?
Yes. The record describes authenticated users, and the vector lists low privileges required. That still matters in any shared instance.
Sources
Last reviewed: 19 October 2026.
