CVE-2026-69259 is a high severity (CVSS 8.8) code injection flaw in Flowise. Before 3.1.3, the SQLite Record Manager let additionalConfig overwrite the database path, so an authenticated user can write files to chosen paths in the root run Docker image. 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 the SQLite Record Manager node spread user controlled additionalConfig after the intended database setting, so additionalConfig.database could overwrite the path. In the published Docker image, which ran as root, an attacker could write a SQLite database to a configuration path that a browser component reads when Puppeteer launches Chromium. By controlling table name and namespace values, the record says shell syntax could end up in that file.
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.
- Run Flowise containers as a non-root user and mount a read only root file system.
- Restrict who can create flows that use the SQLite Record Manager.
- Check the configuration directories of the browser component in your image for files you did not put there.
- Review existing record manager nodes for an unexpected database setting.
- 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 chain is worth studying: a setting that was not meant to be user controlled, a file write to a location the process could reach only because it ran as root, and a later program that read that file as configuration.
Each step looks small. The combination gave code execution. Order of object spreading is a recurring bug, since a spread placed after the safe default lets user data win. Running containers as a non-root user would have broken the chain. The record does not mark this CVE as known exploited.
Quick check
Which image is involved?
The record refers to the published Docker image, which ran as root.
How does a database path lead to code execution?
Per the record, the written file landed in a configuration directory that was read as shell syntax when Chromium launched through Puppeteer.
Sources
- https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3
- Record: NVD entry for CVE-2026-69259 (score 8.8, HIGH)
Last reviewed: 18 October 2026.
