npm · flowise
Flowise: Authenticated arbitrary file write in the `S3 Directory` document loader via unsanitized S3 object keys
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/components/nodes/documentloaders/S3Directory/S3Directory.tsfilePath = path.join(tempDir, key) (unsanitized) mkdirSync creates parent path writeFileSync writes attacker-controlled bytes tempDir, so escapedpackages/components/nodes/documentloaders/S3File/S3File.tspackages/server/src/routes/documentstore/index.ts:41,45/api/v1/document-store/loader/preview,/api/v1/document-store/loader/process/:loaderId) documentStores:preview-process packages/server/src/services/documentstore/index.ts:588 passesdata.loaderConfig straight to the loader node with no pathS3Directory accepts a custom serverUrl, so the attacker does not
need access to an existing trusted AWS bucket — they can point FlowiseIs 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.