CVE-2025-71338 is a maximum severity (CVSS 10.0) flaw in Flowise through version 2.2.7. The document store loader endpoint does not clean path segments, so an unauthenticated caller can write files outside the storage directory and reach remote code execution. Upgrade to a release newer than 2.2.7 and confirm against the advisory.
What's affected
Flowise through 2.2.7, per the record. The record links a release tagged flowise 2.2.7-patch.1, published on 14 March by the maintainer, alongside the GitHub advisory.
The GitHub advisory page lists the affected version as latest and patched versions as none. It does not state a fixed version, so confirm directly in the advisory and the release notes before you rely on a version number. The repository page shows it was archived and made read only on 13 August 2026, which matters for long term support.
How to check if you're exposed
For an npm install:
npm ls flowise
npm ls -g flowise
For containers, read the image tag.
- Compare the version with 2.2.7 and with the patch release named in the record.
- Check whether the service is reachable from outside your private network.
- Check which user the Flowise process runs as, and which files it can write.
- Look for files in application directories that were modified without a deployment.
What to do now
- Take internet exposed Flowise instances offline or behind an authenticating proxy first.
- Upgrade past 2.2.7 and read the advisory for current guidance, since it lists no patched version.
- Run the service as a low privilege user, with a read only application directory where possible.
- Review file integrity on the host. The advisory says files loaded at boot can be overwritten, so check those first.
- Rotate API keys and credentials held by the instance if you find unexplained changes.
- Because the project is archived, plan a longer term decision on whether to keep running it.
Fix the immediate risk first, then the structural one.
Check whether the instance is reachable without a gateway. If it is, put an authenticating proxy in front of it today. The advisory describes an unauthenticated route, so a proxy that requires a login for every path closes the door while you plan the upgrade.
Then look at the host. Run the service under a dedicated account that cannot write to its own program files, and mount the application directory read only where your deployment allows it. This turns a file write bug into a failed write, instead of a path to code that runs at the next restart.
After the upgrade, compare file checksums of the installed application against a clean copy of the release you intended to run. If anything differs, treat the host as suspect, rebuild it from a clean image and rotate every credential it held, including model provider keys and database passwords.
Why it matters
The weakness is CWE-73 (external control of file name or path). A file write endpoint accepted path segments containing parent directory sequences, so a caller could leave the storage folder. The record says application files loaded at boot can then be overwritten, which turns a file write into code execution on restart.
The scope is changed in the vector (S:C), and no authentication is needed, which is how it reaches 10.0.
The record does not mark this as exploited, and it is not in the CISA KEV list. Exploitation should still be assumed easy because the bug class is simple and the advisory is public.
A file write to code execution chain shows up often in web applications, and the pattern is easy to spot once you know it. The application takes part of a path from a request. It joins that part to a base directory. It writes a file there. If the part contains parent directory markers and nobody removes them, the final path can leave the base directory. If the file lands where the application loads code, the write becomes execution.
The defence is well known. Resolve the final path, check that it still sits inside the base directory, and reject the request if not. Better still, do not build paths from request data at all. Generate names on the server and store the user supplied name only as metadata.
This is also a reminder about AI workflow tools in general. Many of them run with broad access to files, network and credentials, because that is what makes them useful. That makes a bug in the HTTP layer more costly than it is in a plain web page, and a good reason to keep these tools off the open internet.
Try it yourself
A dependency alert says Flowise is present. Reachability analysis asks the more useful question, whether the vulnerable code path is actually in use.
Click through it at your own pace, or open it full screen.
Quick check
Is 2.2.7-patch.1 a confirmed fix?
The record links that release, but the GitHub advisory lists no patched version. Treat it as a lead, and verify against the advisory and release notes.
Why is a file write so serious here?
Because files loaded at boot can be replaced, so a write outside the storage directory can become code execution after a restart.
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-8vvx-qvq9-5948
- https://github.com/FlowiseAI/Flowise/releases/tag/flowise%402.2.7-patch.1
Also referenced by the CVE record:
Last reviewed: 19 October 2026.
