CVE-2026-40933 describes a critical vulnerability in the open-source AI workflow platform Flowise that lets an attacker gain full control of a server simply by getting a logged-in user to import a malicious workflow file.
What Obsidian Security disclosed
Obsidian Security disclosed the flaw and published working proof-of-concept (PoC) exploit code showing how an attacker can seize a server. The firm said the bug affects Flowise — a platform for building large language model (LLM) workflows and AI agents that has more than 52,000 GitHub stars — and that self-hosted deployments are vulnerable by default. Obsidian also noted that the managed Flowise Cloud service is not affected.
The Custom MCP stdio transport: how the execution happens
The weakness is located in Flowise’s Custom MCP tool, which integrates external services into the Model Context Protocol (MCP). When that tool is configured to use the stdio transport, Flowise launches a user-supplied command as a child process on the server without any sandboxing. Because Flowise permits users to export and share workflows (chatflows), an attacker can embed a malicious command inside a shared chatflow.
Obsidian found that importing such a chatflow is sufficient to execute the command. The editor automatically queries the configured server as the workflow loads onto the canvas, and there is no requirement to save, run, or approve before the code executes.
Proof-of-concept exploit and the broader research context
Obsidian released a PoC exploit with its disclosure and warned that even the official remediation can be worked around. The firm framed this finding as a continuation of its earlier research into a similar remote code execution (RCE) flaw in Langflow, another open-source AI platform.
Flowise’s patch and why Obsidian says it’s insufficient
Flowise responded to the disclosure by adding an input-validation layer that uses allow lists for permitted commands and blocks risky arguments. Obsidian said this approach addresses the symptom rather than the root cause because the Custom MCP feature is explicitly designed to execute code, and an attacker can still encode malicious behavior within allowed inputs. As a result, Obsidian concluded that self-hosted installations — both open-source and enterprise editions — remain vulnerable by default even on the current release.
Obsidian recommended that the stdio MCP be switched off unless explicitly needed and that the default posture should not leave it running behind validation checks that can be bypassed.
Practical mitigations and operational guidance
According to Obsidian, the most effective protection is to disable the stdio transport by switching Flowise’s Custom MCP protocol to Server-Sent Events (SSE), which removes the execution path entirely. Teams that rely on the stdio feature were urged to treat any imported MCP configuration as code, restrict MCP configurations to trusted sources, and avoid loading shared chatflows from unknown origins.
What this means for self-hosted administrators, enterprise teams, and attackers
- Self-hosted administrators: Systems running Flowise by default should assume exposure unless they have disabled the stdio transport; administrators need to evaluate whether they require stdio and move to SSE where possible.
- Enterprise security and procurement teams: Organizations that deploy Flowise internally should treat imported MCP configurations as executable code, restrict sources of shared chatflows, and review whether the official input-validation patch meets their risk tolerance given Obsidian’s warnings.
- Attackers and threat actors: The vulnerability provides a straightforward exploitation path — embedding commands in shared chatflows — that requires only a logged-in user to import the file. Obsidian’s published PoC demonstrates how practical exploitation can be.
Obsidian’s disclosure, the published PoC, and Flowise’s subsequent validation-based patch leave a narrow operational window for defenders: either remove the stdio execution path entirely by switching to SSE, or accept that allow-listed command validation may be insufficient against determined exploitation. The balance between functionality and safety in features that execute user-provided commands is plain in this case — and for self-hosted deployments, the safer default is the one that prevents execution altogether.
