Flowise on current main allows an authenticated user with
documentStores:preview-process permission to trigger the S3 Directory
document loader with attacker-controlled S3 object keys. The loader joins
each returned S3 key with a temporary directory using path.join(tempDir, key)
and writes the object bytes to disk without validating traversal sequences
such as ../. Cleanup later removes only the original temporary directory,
so files written outside that directory persist on the host filesystem.
This yields arbitrary file write with the privileges of the Flowise
server process.
A related variant exists in the S3File loader when fileProcessingMethod = unstructured (same root cause; its cleanup behavior
turns it into a mixed arbitrary write/delete/DoS primitive).
packages/server/src/services/documentstore/index.ts:588 passes
straight to the loader node
data.loaderConfig
with no path
sanitization
S3Directory accepts a custom serverUrl, so the attacker does not
need access to an existing trusted AWS bucket — they can point Flowise
at a local MinIO or any S3-compatible endpoint they control
Impact
Authenticated arbitrary file write to any path writable by the Flowise
process
Destructive overwrite of application data, secrets, or configuration
Deployment-dependent lift to RCE if the service account can modify
executable, startup, or interpreter-loaded files
(e.g. .bashrc, systemd units, cron files, require.resolve targets, package.json postinstall scripts). This is not guaranteed
product-wide.
Preconditions
Flowise instance running (HTTP server mode)
Attacker has a workspace account with the documentStores:preview-process role
No additional infrastructure required — serverUrl can point to
attacker-controlled S3-compatible endpoint
Proof of Concept
Authenticate as a user with documentStores:preview-process
Run an S3-compatible server the attacker controls (e.g. MinIO)
Create an object with a traversal key such as: ../../../../tmp/flowise-poc.txt
Observe that Flowise writes the object bytes to the escaped path
Observe that cleanup removes only the original temp directory; the
escaped file persists
Local reproduction confirmed: writing a key containing ../../escape-target/poc.txt from a nested temp root created the file
outside the temp directory, and the cleanup removed only tempDir.
Root Cause
The loader trusts S3 object keys as safe local relative paths. It should
canonicalize the destination with path.resolve(...), verify the resolved
path remains within the intended temp directory, and reject traversal or
absolute-path patterns before any directory creation or file write.
Suggested Remediation
The repository already has shared path validators that are not used here: