1-Click RCE in Flowise (CVE-2026-40933)

13ph03nix1 pts0 comments

1-Click RCE in Flowise (CVE-2026-40933): When Is stdio MCP Actually a Vulnerability?

SaaS Security

Platform

Pricing<br>Company

Resources

Company

Free Trial<br>Get a Demo

1-Click RCE in Flowise (CVE-2026-40933): When Is stdio MCP Actually a Vulnerability?<br>Security researchers at Obsidian Security discovered a one-click RCE in Flowise (CVE-2026-40933), an open-source platform for building LLM workflows and AI agents with over 52k GitHub stars. An attacker can fully compromise a server by convincing an authorized user to import a crafted chatflow. Import alone is enough to trigger arbitrary server-side code execution.<br>Published:<br>May 28, 2026

Updated:<br>May 27, 2026

The issue stems from Flowise’s Custom MCP tool support. Users can define custom MCP server configurations with the stdio transport, which launches the configured command as a child process on the Flowise server without sandboxing. A malicious chatflow can embed an attacker-controlled MCP configuration, leading to arbitrary server-side code execution at import time. This grants access to the server environment, stored credentials, API keys, and connected SaaS/cloud environments.<br>Flowise Cloud is not affected, as stdio MCP is disabled. Self-hosted deployments (open-source and enterprise) are vulnerable by default. The current input-validation based fix is easy to circumvent, so the latest version remains affected. If security matters more than functionality, consider disabling stdio MCP by setting CUSTOM_MCP_PROTOCOL=sse.<br>This finding also points to a broader question. Similar code-execution behaviors have been reported across AI platforms, but vendors have responded inconsistently: some treat them as vulnerabilities, while others call them expected behavior. When a feature is designed to execute code, where do we draw the line between intended functionality and a security flaw? We’ll look at a few concrete cases, including OX Security’s MCP disclosures, and explain how we think about that boundary.<br>Background<br>As part of our work to improve the security of the emerging AI application ecosystem, we identify and responsibly disclose vulnerabilities in high-value targets, working with vendors to address issues before they can be exploited.<br>In previous work, we disclosed a critical account takeover and RCE vulnerability in Langflow (CVE-2025-34291), where multiple weaknesses could be chained into full system compromise. Building on that research, we turned to Flowise as the next target in the same category.<br>Flowise is an open-source platform for building LLM workflows and AI agents through a visual editor, where users connect models, tools, and external services. Its role as an orchestration layer makes it particularly sensitive from a security perspective.

MCP as a Code Execution Primitive<br>Stdio MCP<br>To understand the vulnerability, we first need to look at what stdio MCP is. The MCP protocol defines two standard transports: stdio and Streamable HTTP. In the stdio transport, the user specifies a command, arguments, and environment variables in the client's MCP config. The client then launches the MCP server as a child process and exchanges JSON-RPC messages with it over stdin/stdout.<br>For example, a local filesystem MCP server might be configured like this:<br>"mcpServers": {<br>"filesystem": {<br>"command": "npx",<br>"args": [<br>"-y",<br>"@modelcontextprotocol/server-filesystem",<br>"/Users/username/Desktop"<br>}stdio MCP is not an accident of the protocol design. Many MCP tools need access to local resources: files, Git repositories, shells, browsers, and sometimes local credentials. In this model, the server is not isolated from the machine. Local access is often the point. The stdio transport also avoids the authentication and exposed-port concerns of network transports, which makes local deployment simpler and helps speed up adoption.<br>So stdio MCP is, by design, a code execution primitive: the client spawns whatever the config points to, which means anyone who can influence that config gets arbitrary code execution on the host. That may be fine when a local user explicitly configures and launches trusted MCP servers. It becomes a security problem when lower-trust users or untrusted artifacts can influence what gets executed, especially in hosted or shared environments, without safeguards such as sandboxing, allowlisting, or explicit user approval.<br>Even so, many AI platforms support stdio MCP anyway. Much of the MCP ecosystem was built for local developer workflows, and stdio is the easiest way to reuse those tools without turning every local MCP server into a network service.<br>Hardening in Flowise<br>On March 6, 2025, Flowise introduced the Custom MCP Tool in #4136. It passes a user-supplied MCP server configuration to Flowise’s MCPToolkit, which uses the MCP SDK's StdioClientTransport to spawn the configured command as a child process of the Flowise server, with no sandbox or privilege separation. For example, the following configuration runs touch /tmp/pwn on the Flowise...

flowise stdio server security local code

Related Articles