CVE-2025-71333 is a critical (CVSS 9.8) unauthenticated arbitrary file upload in Flowise through version 2.2.4. The /api/v1/attachments endpoint accepts path traversal in two URL parameters when storageType is local. The GitHub advisory lists no patched version, so upgrade past 2.2.4 and confirm in the advisory.
What's affected
Flowise through 2.2.4, per the record and the GitHub advisory. The advisory lists affected versions as 2.2.4 and earlier, and lists patched versions as none. The Flowise repository page shows it was archived and made read only on 13 August 2026.
Only deployments using local storage (storageType set to local) are described as affected. The advisory says that is the default.
How to check if you're exposed
For an npm install:
npm ls flowise
npm ls -g flowise
For Docker, read the image tag you run and compare it with 2.2.4.
- Check the storage setting in your configuration. If it is not local, the described path does not apply, but upgrade anyway.
- Check whether the server is reachable without a gateway in front of it.
- Look in your upload directory for files you do not recognise.
What to do now
- Find every Flowise deployment, including those started for experiments.
- Upgrade beyond 2.2.4 and check the GitHub advisory for the latest statement on fixes.
- Do not expose Flowise directly to the internet. Put it behind an authenticating proxy or a VPN.
- Review the upload and storage directories for unexpected files, and check that the process does not run as a privileged user.
- If you cannot upgrade, move storage off local disk or block the attachments path at the proxy until you can.
If you cannot upgrade at once, put a proxy in front of the service that blocks requests to the attachments path from outside your network. A temporary rule like that costs little, and you can remove it after the upgrade.
Also check where uploads land. If the process can write anywhere its user can read, a traversal bug has a large reach. A dedicated service account, a restricted data directory and a read only application directory shrink that reach.
Finally, treat the archived status of the project as a planning input. A tool that no longer receives changes needs an owner who decides how long it stays in service.
Why it matters
The route is on a list of paths that skip authentication, and it builds a file path from chatflow and chat identifiers in the URL without cleaning them. That is CWE-73 (external control of file name or path). Path traversal in a write operation can place a file outside the intended folder, and the advisory says this can lead to remote code execution and server takeover.
The record does not mark this as exploited, and it is not in the CISA KEV list.
The root of this bug is a gap between two checks. The application has a rule that most routes under the API path need authentication, with a list of exceptions. The attachments route was on that list, because chat users need to attach files. The route then trusted URL parameters when it built a file path. Each decision made sense alone, and together they gave an anonymous caller a way to write to disk.
When you review software like this, two questions help. Which routes skip authentication, and what does each one do with the data it receives. A route that skips authentication should be narrow, and should never use caller data to pick a file name or location.
Try it yourself
Flowise is often pulled in as a transitive piece of a larger stack. A dependency inventory shows where it sits.
Click through it at your own pace, or open it full screen.
Quick check
Is the attachments route protected by the API key?
The advisory says the route is on the public allow list, so the normal authentication check is skipped for it.
If you want a quick look at your own dependencies, the free in-browser scan at gold.safeguard.sh/scan needs no repository access.
Sources
Fetched for this guide:
- https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-h42x-xx2q-6v6g
- https://www.vulncheck.com/advisories/flowise-arbitrary-file-upload-via-unauthenticated-api-v1-attachments-endpoint
Last reviewed: 19 October 2026.
