CVE-2026-46442: Critical Authenticated RCE in Flowise

CVE-2026-46442 is a critical remote code execution flaw in Flowise, the drag and drop builder for large language model flows, scored CVSS 9.9. Any authenticated user or API key can reach a custom function endpoint and run code on the server. Flowise 3.1.2 fixes it, so upgrade to that version or later.

What's affected

The GitHub advisory (GHSA-9rvc-vf7m-pgm2) lists the Flowise npm package at version 3.1.1 and earlier as affected. The patched version is 3.1.2. The NVD record names the product as flowiseai flowise and gives the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

That vector says the attack runs over the network, needs low privileges (a valid login or API key), needs no user interaction, and can change scope, meaning it reaches beyond the application to the host.

How to check if you're exposed

Find every Flowise instance first, including test copies and containers someone started for a hackathon.

1. For an npm install, run npm ls flowise in the project, or npm ls -g flowise for a global install.
2. For Docker, check the image tag you run with docker ps --format '{{.Image}}' and compare it with 3.1.2.
3. Check whether the environment variable E2B_APIKEY is set. Per the advisory, when it is missing Flowise runs submitted code in a local NodeVM sandbox, and that sandbox can be escaped. This is described as the common deployment.
4. List the people and API keys that can log in. The endpoint lacked a route level permission check, so every one of them counts.

Any instance at 3.1.1 or earlier is exposed to the issue described here.

What to do now

1. Upgrade Flowise to 3.1.2 or later on every instance.
2. Review the release notes for 3.1.2 on GitHub, since that release carries many other security changes. The release page I fetched did not name this issue directly, so rely on the advisory for the link between the two.
3. Rotate Flowise API keys that were shared widely or given to third party tools.
4. Remove accounts that no longer need access.
5. Consider configuring the E2B sandbox. The advisory recommends failing closed when E2B_APIKEY is absent instead of silently running code in NodeVM. Check the advisory for what 3.1.2 changes here.
6. Run the host as a low privilege user, and keep Flowise off the open internet where you can.

The advisory lists no separate workaround. If you cannot upgrade today, limiting who holds an account or key is a sensible stopgap, but that is a judgment call and not vendor guidance.

Why it matters

The weakness is CWE-94, improper control of code generation, or code injection. Flowise has a node that lets users write their own JavaScript. That is a feature, and it is only safe when two things hold: only trusted people can reach it, and the sandbox around it holds.

According to the advisory, both failed. The endpoint had no permission check, so any authenticated identity could submit code. And the local sandbox can be escaped through an error object, which exposes the host process and lets code run system commands.

The record's KEV flag is false, and the advisory I read does not say the flaw is exploited. Even so, a 9.9 on a tool that often holds model provider keys and database credentials deserves a quick patch.

Try it yourself

This demo shows how exploitability checks help you rank findings like this one against the rest of your list.

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

You can also run the free in-browser dependency scan at gold.safeguard.sh/scan against your manifest to see whether Flowise or its dependencies appear.

Quick check

Sources

• Flowise GitHub advisory GHSA-9rvc-vf7m-pgm2
• Flowise 3.1.2 release notes
• Gold page for this CVE

Last reviewed: 19 October 2026.