CVE-2026-69255 is a high severity (CVSS 8.8) code injection flaw in Flowise. Before 3.1.3, CSVAgent put attacker controlled CSV data directly into executable Python run through Pyodide, so an authenticated attacker can run operating system commands. Upgrade to Flowise 3.1.3.
What's affected
The record says Flowise before 3.1.3 is affected, and that the issue is fixed in 3.1.3. Fixed in Flowise 3.1.3, which the project published as a GitHub release. The release page I retrieved shows the repository as archived and read only by its owner since 13 August 2026. That does not change the advice to run 3.1.3 or later, but it does mean you should check where future security fixes will come from before you rely on this project long term.
The record says CSVAgent extracted data from the uploaded CSV and interpolated it directly into Python source before calling Pyodide. A denylist, validatePythonCodeForDataFrame, checked only later LLM generated code and did not check this first block. The record says an attacker could reach the Node.js child process module through Pyodide and run commands as root in the Flowise container.
I relied on the record for the technical description of this CVE. The 3.1.3 release page was the only vendor page I retrieved, and it does not give a per-CVE explanation.
How to check if you're exposed
npm ls -g flowise
docker image ls | grep -i flowise
The first command shows a global npm install, the second any Flowise container image and its tag. If you run it from a compose file or a Kubernetes manifest, read the image tag there. Anything below 3.1.3 is in scope.
Then find who can reach the affected feature. In most deployments the first control is who holds a login or an API key, so list those too. Every path described in the record needs some level of access, or in the unauthenticated case, only network reach to the service.
A quicker route for a whole project is the free in-browser dependency scan at Gold. Paste a manifest or lockfile and it matches each dependency against known CVEs, including ones pulled in indirectly.
What to do now
- Upgrade Flowise to 3.1.3 or later and redeploy all instances, including containers built from older images.
- Disable or remove CSV Agent nodes in flows until the upgrade is done, if you can.
- Restrict who can upload files to flows that use CSV Agent.
- Run Flowise as a non-root user inside a container with limited network egress.
- Review uploaded CSVs and flow logs for unusual content.
- Check whether the project's archived status affects your support plan, and decide on an owner for security updates.
- Run Flowise behind authentication and a network boundary, and do not expose its admin or API ports directly to the internet.
Reachability analysis helps with ordering the work. Knowing whether your code actually calls the affected path tells you which services to patch first.
Why it matters
The weakness is CWE-94, improper control of generated code. Two mistakes combined. Untrusted file content was joined into a code string, and the safety check covered code from the model but not code the application built itself.
Denylists are a weak defence for this reason: they only catch what their authors thought of, and only where they are applied. Pass file content to the interpreter as data, not as part of the program text. The record does not mark this CVE as known exploited.
Quick check
What input triggers it?
Attacker controlled CSV data, per the record, in a flow that uses the CSV Agent.
Does the denylist stop it?
No. The record says it checked only later LLM generated code, not this initial block.
Sources
- https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3
- Record: NVD entry for CVE-2026-69255 (score 8.8, HIGH)
Last reviewed: 18 October 2026.
