Four Flowise CVEs Reach From MCP Configuration to RCE, Cross-Workspace Tools, and Key Theft

2026-09-16 AI Vulnerabilities & CVEs by al-ice.ai Editorial

Four CVE records published September 15 expose a shared authorization problem in Flowise: ordinary workflow configuration could select not only what an AI application should do, but also which programs the server launches, which workspace’s tools it invokes, and where provider credentials are sent.

CVE-2026-91931 and CVE-2026-91932 cover two authenticated code-execution paths in the Custom MCP node. CVE-2026-91933 covers cross-workspace disclosure and execution of ChatFlow tools through OpenAI Realtime endpoints. CVE-2026-91935 covers user-controlled model base URLs that can create server-side requests and send an LLM provider key to an attacker-selected endpoint.

The affected boundary is Flowise before 3.1.4. The vendor’s GitHub advisories rate the two MCP execution flaws at 9.0, the cross-workspace flaw at 7.6, and the base-URL flaw at 9.4 under CVSS 4.0. All four require an authenticated Flowise identity or a permission-bearing API context; none of the records establishes unauthenticated internet-wide compromise or exploitation in the wild. The practical blast radius depends on the user’s Flowise permissions, the tools and credentials configured in the targeted flow, and the filesystem, network, and cloud access granted to the Flowise process.

The disclosure timeline also matters. Flowise 3.1.4 was released July 29, and the vendor advisories became public August 31. The CVE records arrived September 15. Operators already on 3.1.4 have the named fixes; the new CVE publication does not indicate that the patched version has regressed.

An allowlist included a package runner

CVE-2026-91931 is not a conventional shell-metacharacter injection. Flowise’s Custom MCP validation explicitly allowed several executable names, including npx, while blocking selected dangerous flags. That distinction did not provide a security boundary: the normal purpose of npx is to obtain and execute npm package binaries. An authenticated user could therefore supply a package name in the MCP configuration and cause package-controlled code to start on the Flowise server before MCP initialization determined whether the process was a valid server.

The advisory’s validation used a harmless file-creation side effect and observed that Flowise returned “No Available Actions” while the side effect still occurred. That ordering is important for defenders. A failed MCP handshake is not evidence that no process ran; process launch precedes protocol validation.

CVE-2026-91932 reaches the same subprocess boundary through a different field. The validator checked command, args, and environment values but did not check the stdio transport’s cwd field. A clean relative filename could pass argument validation while an attacker-selected working directory changed which file the runtime executed. Exploitation therefore requires an authenticated user and executable attacker-controlled content at a usable path; it is not an arbitrary remote shell from the cwd value alone.

Flowise 3.1.4 changes the trust model rather than extending the old static list. CUSTOM_MCP_ALLOWED_COMMANDS is empty by default, so no Custom MCP stdio command is accepted until an operator opts in. The patched validator rejects cwd entirely. Operators who add npx, a generic interpreter, or a broad executable path back to the allowlist are reintroducing powerful execution semantics by configuration even though the named validation defects are patched.

A ChatFlow ID crossed the workspace boundary

CVE-2026-91933 shows why route authentication and object authorization are separate controls. The affected GET and POST OpenAI Realtime routes accepted a caller-supplied ChatFlow identifier, loaded that object directly, and initialized its tools without first proving that the ChatFlow belonged to the caller’s active workspace.

A credential from one workspace could consequently retrieve another workspace’s tool definitions and invoke a selected tool. The impact was not limited to metadata: the POST route returned tool output and could trigger whatever external side effects the victim tool was authorized to perform. The attacker still needed a valid Flowise credential and the target ChatFlow identifier; the flaw did not make every flow anonymously enumerable.

The 3.1.4 patch adds route-level ChatFlow permissions, passes the authenticated user’s active workspace into the service, and resolves the ChatFlow through a workspace-scoped lookup. This is the correct control point: authorization is bound to the object before credentials are loaded and before a tool is initialized, rather than inferred from possession of an opaque ID.

Model endpoint flexibility became a credential-routing primitive

CVE-2026-91935 affected eight chat-model integrations whose configurable baseURL or basepath was handed to an underlying LangChain or provider SDK without Flowise’s normal outbound-URL check. An authenticated member with ChatFlow create or update permission could direct server-side requests toward an internal address or an attacker-controlled service.

The credential consequence is more direct than generic SSRF. Provider SDKs commonly attach the configured model API key as an Authorization header to requests sent to the selected base URL. If a legitimate credential and an attacker-selected endpoint were combined in the same node, the SDK could deliver the key to that endpoint. The advisory names ChatOpenAICustom, two ChatOllama variants, ChatLocalAI, ChatLitellm, ChatNvdiaNIM, ChatNemoGuardrails, ChatCloudflareWorkersAI, and ChatGoogleGenerativeAI.

Flowise already had a shared checkDenyList control for many outbound HTTP features. The affected model nodes bypassed it because the request was made by the provider SDK. The 3.1.4 patch invokes that check before accepting the custom endpoint in the named nodes. That closes the published paths, but egress policy remains valuable: URL validation and SDK behavior can diverge around DNS, redirects, proxies, IPv6 forms, and future integrations, while a network boundary can independently prevent the Flowise workload from reaching cloud metadata and unrelated internal control planes.

The common failure was delegating authority through configuration

These flaws are different CWEs—command or code execution, missing object authorization, and SSRF—but the architectural mistake is consistent. A low-friction builder treated workflow fields as application data even when those fields selected an operating-system process, an authorization tenant, or a network trust destination.

That matters especially in agent platforms because “editor” is often understood as a content role. In practice, editing an agent may grant the ability to choose executables, attach production credentials, address internal services, and invoke tools with external side effects. The role is closer to deployment authority than document editing.

The batch also extends Flowise’s recurring MCP execution history. Earlier CVE-2026-40933 showed that imported MCP stdio configuration could reach server execution. The new records demonstrate residual paths after argument-focused filtering: a permitted package runner, an unchecked working directory, and adjacent authorization and endpoint-routing gaps. A blacklist around command syntax cannot safely convert a general process launcher into a multi-tenant feature.

What defenders should do now

Upgrade every Flowise component to 3.1.4 or later. Check the running server and flowise-components versions, not only a lockfile or image tag. Recreate containers after updating and confirm that old replicas and workers are gone.
Keep Custom MCP stdio disabled by default. Leave CUSTOM_MCP_ALLOWED_COMMANDS empty unless the deployment genuinely needs local subprocess MCP. Prefer remote, authenticated MCP transports or administrator-installed binaries with exact paths over package managers and general interpreters.
Treat any opt-in as code-deployment permission. If npx, node, Python, or Docker is enabled, restrict who can create and update the corresponding nodes. Do not rely on blocked flags to make a general execution engine safe.
Review tenant authorization independently of route login. Test that users and API keys from one workspace cannot read or invoke ChatFlows, credentials, tools, files, or runs from another by changing an identifier.
Constrain egress from Flowise. Block cloud metadata, loopback services not required by the application, private management ranges, and arbitrary internet destinations. Route approved model providers through explicit proxies or destination policies.
Rotate credentials if untrusted editors controlled model endpoints. Prioritize LLM provider keys and any secrets available to affected ChatFlows. Review provider access logs for unexpected source addresses, hosts, spend, models, or request timing.
Hunt for process-launch evidence. Examine Flowise and container logs, npm cache and install activity, child processes, filesystem changes, outbound DNS and HTTP traffic, and failed Custom MCP action-discovery events. A protocol error may have followed a successful process start.
Audit current configuration after patching. Identify custom MCP nodes, configured baseURL/basepath values, OpenAI Realtime integrations, public ChatFlows, broad workspace roles, and host or Docker-socket mounts. The upgrade prevents the published flaws; it does not remove risky operator-granted capabilities.

The defensive lesson is broader than Flowise: agent configuration is executable policy. Any field that selects a command, working directory, endpoint, object ID, tool, or credential destination must be authorized against the caller and validated at the point where the action occurs. UI labels such as “node,” “flow,” or “integration” do not reduce the authority those fields carry.

Sources: