CVE-2026-69254 is a high severity (CVSS 8.8) code injection flaw in Flowise. Before 3.1.3, executeJavaScriptCode merged caller supplied NodeVM options over its security defaults, so an authenticated user can run system commands, as root in the cited setup. 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 executeJavaScriptCode accepted caller provided nodeVMOptions and merged them over the default NodeVM security settings. An authenticated attacker who could reach the custom function route could run a function that called the same helper again with the module allow list widened, and so reach operating system commands. The record says this ran as root on the Flowise server in the cited deployment.
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.
- Restrict who can create custom functions and tools, and review existing ones.
- Run the Flowise container as a non-root user with a read only root file system.
- Remove unneeded credentials and cloud roles from the Flowise runtime.
- Review server logs for unexpected child processes.
- 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 class is CWE-94, improper control of generated code. The sandbox had a sensible default policy, but the helper that applied it also let the code inside the sandbox supply its own policy. Security settings that the sandboxed code can reach are not a boundary.
The fix pattern is to keep the policy outside the caller's reach: fixed options, no merge from untrusted input, and no import of the helper from inside the sandbox. Running as root made the impact worse. The record does not mark this CVE as known exploited.
Quick check
Does it need a login?
Yes, the record says an authenticated attacker who can reach the custom function route.
Why does root matter?
The record says commands ran as root, so a container or host breach would start with full privileges.
Sources
- https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3
- Record: NVD entry for CVE-2026-69254 (score 8.8, HIGH)
Last reviewed: 18 October 2026.
