GHSA-88pr-878c-24wf Flowise on current `main` allows an authenticated user with `documentStores:preview-process` permission to trigger the `S3 Direct

Summary

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).

Affected component

• packages/components/nodes/documentloaders/S3Directory/S3Directory.ts
  • line 191: filePath = path.join(tempDir, key) (unsanitized)
  • line 213: recursive mkdirSync creates parent path
  • line 216: writeFileSync writes attacker-controlled bytes
  • line 289: cleanup only removes the original tempDir, so escaped
    files remain on disk
• Related (variant):
  packages/components/nodes/documentloaders/S3File/S3File.ts
  (lines 756, 780, 782, 817 — arbitrary write + recursive dirname delete)

Reachability

• Routes exposed:
  packages/server/src/routes/documentstore/index.ts:41,45
  (/api/v1/document-store/loader/preview,
  /api/v1/document-store/loader/process/:loaderId)
• Both require documentStores:preview-process
• packages/server/src/services/documentstore/index.ts:588 passes
  data.loaderConfig straight to the loader node 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