Businesses using Flowise’s lightweight, open-source platform to power their hosted AI workloads have a new high-severity problem to worry about.
Obsidian Security researchers have described a remote code execution (RCE) vulnerability affecting self-hosted Flowise deployments through its use of Model Context Protocol (MCP) stdio servers.
The problem is a sandboxing failure of an attacker-controlled MCP configuration, which leads to server-side code execution.
“Post-auth RCE in Flowise can be initiated with a single click by importing a malicious dialog before saving or executing,” the researchers said in a blog post. “The legitimate episode depends on validating the input which is slightly overridden and fails to correct the origin.”
Flowise is commonly used to develop internal AI assistants, retrieval-augmented generation (RAG) systems, customer-facing chatbots, and autonomous agents connected to business systems.
The bug does not affect Flowise Cloud, as stdio MCP is disabled there. On the other hand, when a feature is enabled and really needed, there is a security and performance tradeoff that developers need to understand and actively review server configurations for potential threats, the researchers explained.
One click of RCE affects everything that Flowise can access
The vulnerability, tracked as CVE-2026-40933, affects the Flowise implementation of MCP stdio servers. MCP stdio is designed to launch local server processes and interact with them using standard input and output, allowing AI agents to interact with files, Git repositories, databases, browsers, and local data.
According to Obsidian Security, the problem stems from Flowise allowing users to configure MCP stdio servers that contain invalid commands. Because those commands are ultimately executed by the underlying operating system, an attacker can achieve remote code execution with Flowise process permissions.
In containerized deployments, the researchers noted, this can effectively provide root-level access to the host platform.
The bug was given a rating of 9.9 CVSS, with potential mitigations that could expose API keys, databases, cloud services, SaaS applications, and other assets accessible through Flowise.
Researchers say the fix is lacking
The disclosure describes a series of fixes made by Flowise that are intended to limit how MCP stdio commands can be configured and executed. According to Obsidian, however, each iteration relies heavily on command validation and filtering methods that can be overridden under certain circumstances.
“Flowise appeared to be risk-averse and hardened the Desired MCP over multiple rounds,” the researchers noted. “#5232 introduced CUSTOM_MCP_SECURITY_CHECK, an automatically enabled authentication layer for Custom MCP configurations.” While the checks narrowed down the obvious ways to issue the command, it did little to reverse the underlying threat of allowing users to provide stdio MCP configurations, they said.
Obsidian’s reporting of a bug resulted in continued feature stabilization with flag validation in updates #5741 and #5943. Even these, did not completely eliminate the threat.
When asked to treat stdio MCP as insecure by default and requiring graphics access, Flowise reportedly said they wanted to “limit what we know is bad without completely disabling features that users can rely on.” Obsidian has shared a proof of concept (POC) with exploit code on how Flowise’s current defenses can be bypassed to defeat RCE.
The only complete mitigation recommended by researchers is to disable MCP stdio by setting “CUSTOM_MCP_PROTOCOL=sse”. For those who can, without disrupting performance, pinning trusted packages where possible, and reviewing imported chat flows from untrusted sources can help, the researchers added.
