Flowise CVE-2026-40933: importing a shared chatflow is enough for RCE

What is this?

Flowise is a popular open-source, drag-and-drop builder for LLM workflows and AI agents (over 52k GitHub stars). One of its building blocks is the Custom MCP node, which lets a chatflow connect to a Model Context Protocol server using a user-supplied JSON config.

CVE-2026-40933 — “Flowise: Authenticated RCE Via MCP Adapters,” published to the GitHub Advisory Database on April 16, 2026 (GHSA-c9gw-hvqq-f33r) — covers the fact that a Custom MCP config using the stdio transport makes the Flowise server spawn whatever command the config names, with no sandbox. On May 28, 2026, Obsidian Security published a detailed write-up showing the most uncomfortable part of the bug: an attacker does not need to convince a victim to run anything. Importing a shared chatflow can be enough to trigger execution. The GitHub-reviewed severity is critical; the published CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Affected versions are flowise and flowise-components <= 3.0.13; the advisory lists the fix in 3.1.0.

How it works

The stdio MCP transport is, by design, a code-execution primitive: the client is handed a command, optional args, and env, and it launches that command as a child process to exchange JSON-RPC over standard input/output. When the thing that controls the config is a low-trust user — or an imported artifact — that primitive becomes arbitrary code execution on the host.

Flowise added an input-validation layer (CUSTOM_MCP_SECURITY_CHECK) that allowlists a handful of launchers (node, npx, python, python3, docker), blocks traversal patterns, and strips shell metacharacters. The problem, as both the GitHub advisory and Obsidian document, is that an allowlisted launcher combined with a code-running argument still executes code. Conceptually:

{
  "command": "<allowlisted-launcher>",   // passes the command allowlist
  "args": ["<flag-that-evaluates-code>", "<REDACTED>"]
}

The exact payloads are public in the advisory and the researcher write-up; they are intentionally not reproduced here. The point is structural: input validation reduces obvious paths to execution but does not remove the underlying capability, because malicious behaviour can be expressed inside the feature’s valid input space.

The “1-click” escalation is the genuinely fresh finding. Flowise’s Custom MCP node has an “Available Actions” dropdown that enumerates the tools a configured MCP server exposes. With stdio, enumerating tools means starting the configured command — and that enumeration fires when the imported chatflow first renders on the canvas. So a victim who imports a “promising” shared chatflow JSON to see what it does can trigger server-side execution before any save or run, with no approval prompt. Obsidian tested this against Flowise 3.1.2 and reported that the validation-based hardening was still circumventable at that release.

This is the agent-platform instance of a broader pattern we have covered: prompts and configs becoming shells. Here the untrusted input is not a prompt but a shared workflow file.

Why it matters

Flowise typically sits at the orchestration layer, wired into databases, API keys, and cloud accounts. Code execution in that process means every stored credential is readable and every connected service is reachable — in containerized deployments the process is often root, so the blast radius is the whole container and whatever it can reach.

The exposure is not theoretical. A separate, earlier Flowise Custom MCP flaw — CVE-2025-59528 (CVSS 10.0, a JavaScript injection via the Function() constructor, patched in 3.0.6) — saw its first in-the-wild exploitation on April 6, 2026, per VulnCheck, with roughly 12,000–15,000 Flowise instances exposed on the public internet at the time. The same class of node has now produced multiple critical CVEs and active attacks. Flowise Cloud is not affected because stdio MCP is disabled there; self-hosted deployments are the risk.

Defenses

1. Disable stdio MCP if you don’t need it. Set CUSTOM_MCP_PROTOCOL=sse. Obsidian calls this the most effective mitigation, and it removes the execution primitive rather than trying to filter it.
2. Do not rely on input validation alone. CUSTOM_MCP_SECURITY_CHECK is enabled by default but has documented bypasses. Treat it as defense-in-depth, not the boundary.
3. Upgrade, then verify. Move off flowise/flowise-components <= 3.0.13; the advisory lists 3.1.0 as the fix. Also confirm you are past 3.0.6 to close CVE-2025-59528. Re-test that your config does not still allow launcher-plus-code-flag combinations.
4. Treat imported chatflows as untrusted code. A shared chatflow JSON can carry an MCP config that runs at import time. Review chatflows before importing, and never import from unknown sources on a server that holds real credentials.
5. Keep Flowise off the public internet. Put it behind authentication and a VPN/allowlist. The exposed-instance counts above are why scanners find these so quickly.
6. Isolate and least-privilege the runtime. Run Flowise in a sandboxed container as a non-root user, with egress filtering and scoped credentials, so that an MCP code-execution event is contained rather than catastrophic.

Status

Item	Reference	Date	Notes
CVE-2026-40933 advisory (GHSA-c9gw-hvqq-f33r)	GitHub Advisory Database	2026-04-16	Authenticated RCE via MCP adapters; affects <= 3.0.13; fixed in 3.1.0; CWE-78
Obsidian Security write-up (1-click import RCE)	Obsidian Security	2026-05-28	Import-time enumeration triggers execution; validation bypassable at 3.1.2
CVE-2025-59528 (Custom MCP Function() injection)	GitHub Advisory Database / NVD	2025-09 → patched 3.0.6	CVSS 10.0; sibling flaw in the same node
In-the-wild exploitation of CVE-2025-59528	VulnCheck via CSO Online	2026-04-06	~12k–15k exposed instances; first observed exploitation

The framing that matters: with stdio MCP, whoever influences the config gets code execution, and on a shared platform that includes a chatflow file someone imports. Filtering arguments narrows the path; only disabling the primitive or sandboxing the runtime closes it.