Enterprises using the lightweight, open-source Flowise platform to power self-hosted AI workloads now have a new near-max-severity issue to worry about.
Researchers at Obsidian Security have detailed a one-click remote code execution (RCE) vulnerability affecting self-hosted Flowise deployments through its implementation of Model Context Protocol (MCP) stdio servers.
The problem is essentially a sandboxing failure of attacker-controlled MCP configurations, leading to server-side code execution.
“Post-auth RCE in Flowise can be triggered with a single click via a malicious chatflow import before any save or run,” the researchers said in a blog post. “The official patch relies on input validation that is trivially bypassed and fails to address the root cause.”
Flowise is commonly used to develop internal AI assistants, retrieval-augmented generation (RAG) applications, customer-facing chatbots, and autonomous agents connected to business systems.
The flaw does not affect Flowise Cloud, as stdio MCP is disabled there. For the rest, where the feature is enabled and is absolutely necessary, there is a security and functionality tradeoff developers need to understand and actively review server configurations for possible threats, the researchers explained.
Once-click RCE affects everything Flowise can reach
The vulnerability, tracked as CVE-2026-40933, affects Flowise’s implementation of MCP stdio servers. MCP’s stdio is designed to launch local server processes and communicate with them through standard input and output streams, allowing AI agents to interact with files, Git repositories, databases, browsers, and local credentials.
According to Obsidian Security, the issue stems from Flowise allowing users to configure MCP stdio servers containing arbitrary commands. Because those commands are ultimately executed by the underlying operating system, an attacker can achieve remote code execution with the privileges of the Flowise process.
In containerized deployments, the researchers noted, this can effectively provide root-level access to the environment hosting the platform.
The flaw has been assigned a 9.9 CVSS rating, with a successful compromise potentially exposing API keys, databases, cloud resources, SaaS applications, and other assets accessible through Flowise.
Researchers said the fixes fall short
The disclosure details a series of remediation efforts by Flowise aimed at restricting how MCP stdio commands can be configured and executed. According to Obsidian, however, each iteration relied primarily on command validation and filtering mechanisms that can be bypassed under certain conditions.
“Flowise appeared to acknowledge the risk and hardened Custom MCP over several rounds,” the researchers noted. “#5232 introduced CUSTOM_MCP_SECURITY_CHECK, a default-enabled validation layer for Custom MCP configurations.” While the checks reduced obvious command execution paths, they did little to change the underlying threat of allowing users to supply stdio MCP configurations, they said.
Obsidian’s reporting of the flaw triggered further hardening of the feature with flag validation in updates #5741 and #5943. These, too, did not entirely remove the threat.
When requested to treat stdio MCP as unsafe by default and require explicit opt-in, Flowise reportedly said they wanted to “limit what we know is bad without completely disabling features that users may rely on.” Obsidian shared a proof-of-concept (POC) exploit demonstrating how Flowise’s current protections could still be bypassed to achieve successful RCE.
The only complete mitigation recommended by the researchers is turning off MCP stdio by setting “CUSTOM_MCP_PROTOCOL=sse”. For those who can’t, without obstructing operations, pinning trusted packages where possible, and reviewing imported chatflows from untrusted sources might help, the researchers added.
The article originally appeared on CSO.
