CVE-2026-69251 is a high severity (CVSS 8.8) code injection flaw in Flowise. Before 3.1.3, record manager and agent memory nodes let users set arbitrary TypeORM DataSource options through additionalConfig, which can load local JavaScript files. An authenticated user can reach server code execution. 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 lists MySQL, Postgres and SQLite record manager nodes, and the MySQL and general agent memory nodes, as taking an additionalConfig input. It says TypeORM DataSource options such as entities, subscribers and migrations can load local JavaScript files, so an authenticated user who can place a file on the server and reference it can run code.
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.
- Review who can create and edit flows, and remove edit rights from anyone who does not need them.
- Check existing flows for record manager and memory nodes that set additionalConfig, and read what each sets.
- Run the Flowise process as a non-root user with a read only file system where practical.
- Limit what files authenticated users can upload to the server.
- 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 node was meant to let an operator tune a database connection, but it passed a free form object straight to the library that sets up the connection. Some of that library's settings are not data. They tell it which code files to load.
The general lesson applies to any configuration pass through: allow a short list of known safe keys, and reject the rest. The record requires an authenticated user, which in an LLM workflow tool often means any team member who can edit flows. It does not mark this CVE as known exploited.
Quick check
Does this need a login?
Yes, the record says an authenticated user is required.
Why is a database setting dangerous?
Some TypeORM options name JavaScript files to load, so passing them through unfiltered lets a user cause code to run.
Sources
- https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3
- Record: NVD entry for CVE-2026-69251 (score 8.8, HIGH)
Last reviewed: 18 October 2026.
