A significant vulnerability has been identified in the open-source artificial intelligence platform Flowise, with evidence of working proof-of-concept (PoC) code that enables a malicious actor to gain control over a server. This critical flaw arises when a logged-in user imports a hazardous workflow file, potentially compromising the security of their systems.
As detailed in a recent analysis by Obsidian Security, this vulnerability is tracked as CVE-2026-40933. It affects Flowise, a platform renowned for its ability to create large language model (LLM) workflows and develop AI agents, boasting over 52,000 stars on GitHub. Notably, self-hosted installations of Flowise are inherently vulnerable, while users of the managed Flowise Cloud service remain unaffected, highlighting a significant disparity in security depending on deployment choices.
This discovery is part of a broader investigation by Obsidian Security, which has previously uncovered similar remote code execution (RCE) vulnerabilities in other open-source platforms, such as Langflow. With their recent findings, Obsidian has released a PoC exploit that demonstrates how this vulnerability can be leveraged. They emphasized that the current official patch could be bypassed, leaving the latest version of Flowise still exposed to potential exploitation.
### Custom MCP Tool as a Point of Exploitation
The vulnerability lies specifically within Flowise’s Custom Model Context Protocol (MCP) tool, which is designed to integrate external services. When configured to use the stdio transport, this tool executes user-supplied commands as child processes on the Flowise server, curiously without any sandboxing measures in place. This lack of protective barriers raises serious concerns, as it allows for the direct execution of commands provided by users.
Given that Flowise allows for the export and sharing of workflows—termed chatflows—an attacker could easily embed a harmful command within one of these files. Obsidian’s analysis revealed that merely importing a compromised chatflow is sufficient to trigger the execution of the command. This occurs because the editor automatically queries the configured server when a workflow loads onto the canvas, with no requirement for further actions such as saving or approving the command before it runs.
### An Insufficient Patch
In response to the discovery of this flaw, Flowise has implemented an input-validation layer aimed at blocking unauthorized commands while allowing safe arguments. However, Obsidian Security has critiqued this approach as addressing only the symptoms rather than the root cause of the issue. The inherent design of this feature necessitates code execution, meaning that an attacker can still conduct malicious activities within the confines of permitted input parameters.
Consequently, self-hosted installations—including both open-source and enterprise versions—remain vulnerable even after the introduction of this patch. Obsidian has strongly recommended that organizations operating these versions disable the stdio MCP unless absolutely necessary. They argue that the feature should not be left enabled under validation controls that are susceptible to circumvention.
The analysis suggests that the most robust defense against potential exploitation is to disable the stdio transport entirely. Organizations are encouraged to switch Flowise’s Custom MCP protocol to the Server-Sent Events (SSE) configuration, which effectively eliminates the risk of command execution through this pathway.
### Best Practices for Mitigation
As organizations explore these tools for building AI workflows, it is imperative to treat any imported MCP configuration as code. This means implementing rigorous restrictions to trusted sources and avoiding the inclusion of shared chatflows from unknown or potentially dangerous origins. With the growing reliance on open-source platforms for AI development, maintaining vigilance about security vulnerabilities and adopting best practices is crucial for safeguarding against exploitation.
The ramifications of such vulnerabilities extend beyond individual systems, emphasizing the need for continuous scrutiny and timely intervention in the ever-evolving landscape of open-source technology. As organizations navigate these complexities, robust security measures and a proactive stance on vulnerability management are key to protecting their infrastructures and data.