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

> Authenticated users can write arbitrary files to the server via unsanitized S3 keys, potentially leading to code execution or data modification.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 4 Aug 2026

## What is GHSA-88pr-878c-24wf?

GHSA-88pr-878c-24wf is a path traversal vulnerability in flowise, published on 4 Aug 2026. Any signed-in user can exploit it over the network, with no action from the victim.

### Official description

## 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

## Which versions are affected by GHSA-88pr-878c-24wf?

4 open source packages ship an affected version, including flowise and flowise-components.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `flowise` | npm | All versions | 3.1.3 |
| `flowise` | npm | All versions | 3.1.3 |
| `flowise-components` | npm | All versions | 3.1.3 |
| `flowise-components` | npm | All versions | 3.1.3 |

## How do I fix GHSA-88pr-878c-24wf?

Upgrade flowise to 3.1.3 or later.

## Is GHSA-88pr-878c-24wf being exploited?

There is no known exploitation of GHSA-88pr-878c-24wf in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-88pr-878c-24wf and fix it if it is affected.

What it is: GHSA-88pr-878c-24wf is a path traversal vulnerability in flowise, published on 4 Aug 2026. Any signed-in user can exploit it over the network, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-88pr-878c-24wf in the wild and no public exploit code.

Affected packages and fixed versions:
- flowise (npm): affected all versions; fixed in 3.1.3
- flowise (npm): affected all versions; fixed in 3.1.3
- flowise-components (npm): affected all versions; fixed in 3.1.3
- flowise-components (npm): affected all versions; fixed in 3.1.3

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-88pr-878c-24wf/ (Markdown: https://insights.sbomify.com/GHSA-88pr-878c-24wf/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-88pr-878c-24wf

---
From sbomify Insights: https://insights.sbomify.com/GHSA-88pr-878c-24wf/
Summaries are generated and may contain mistakes; the official description above is the record.
