Safeguard
Vulnerability Analysis•

CVE-2026-69253: High Code Injection via baseURL in Flowise Tools

Flowise before 3.1.3 builds sandboxed tool code from an unescaped baseURL, letting an authenticated user escape the vm2 sandbox. Upgrade to 3.1.3.

Safeguard Security Team
4 min read

CVE-2026-69253 is a high severity (CVSS 8.8) code injection flaw in Flowise. Before 3.1.3, the AgentAsTool, ChatflowTool and ExecuteFlow components put a user controlled baseURL into generated JavaScript, and an authenticated user can break out of the vm2 sandbox. 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 names three components, AgentAsTool, ChatflowTool and ExecuteFlow. They run code in an in-process vm2 sandbox and built that code by inserting a baseURL value into the source text. The only check was whether the value was a valid URL, which does not stop characters that end a string. The record says the sandbox shares a Node.js process with Flowise and exposes risky dependencies, so code that escapes it runs on the server.

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

  1. Upgrade Flowise to 3.1.3 or later and redeploy all instances, including containers built from older images.
  2. Review which users can build or edit flows that use these three tool components.
  3. Treat baseURL values in saved flows as untrusted and inspect them for unusual characters.
  4. Run the server with minimal privileges and no access to production secrets it does not need.
  5. Scan your own custom tool code for string built scripts.
  6. Check whether the project's archived status affects your support plan, and decide on an owner for security updates.
  7. 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

This one carries CWE-95, eval injection, and CWE-94, code injection. The pattern is building source code by joining strings. A value that is safe as a URL may not be safe inside a quoted JavaScript string, because the checks answer different questions.

Two lessons follow. First, pass data into a sandbox as data, as a variable or argument, never by editing the code text. Second, an in-process sandbox is a thin boundary. The record describes the escape as running arbitrary code on the Flowise server. Static code analysis is well suited to finding this class of mistake in your own tool code. The record does not mark this CVE as known exploited.

Try it yourself

This demo shows how static analysis finds code that builds scripts from unescaped input, the pattern behind this flaw.

Click through it at your own pace, or open it full screen.

Quick check

Is the sandbox enough protection?

The record says the vm2 sandbox runs in the same Node.js process and exposes risky dependencies, so an escape reaches the server.

Who can exploit it?

An authenticated user, per the record.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.