# Critical Flowise RCE Flaw Now Exploitable—Public PoC Puts 52K-Star AI Platform at Risk


## The Threat


Obsidian Security has published proof-of-concept code for a critical remote code execution vulnerability in Flowise, the widely-adopted open source platform for building AI agents and large language model (LLM) workflows. Tracked as CVE-2026-40933 with a maximum CVSS score of 9.9, the flaw allows attackers to execute arbitrary code on self-hosted Flowise servers through a single malicious action: importing a crafted chatflow.


Flowise, which boasts over 52,000 GitHub stars and is used by enterprises and developers globally to create drag-and-drop AI workflows, contains a systemic design flaw in how it handles Anthropic's MCP (Model Context Protocol) configurations. The vulnerability stems from unsafe serialization of stdio commands within the MCP adapter—a weakness that security researchers say is "by design" rather than an implementation bug, meaning it affects the entire ecosystem of applications built on MCP.


The attack is deceptively simple: an attacker crafts a Flowise chatflow containing a malicious Custom MCP Tool with arbitrary system commands embedded in the stdio configuration, exports it as JSON, and shares it with a victim. When that victim imports the chatflow into their Flowise instance, the platform automatically enumerates the MCP server's available tools to populate a dropdown menu—and this enumeration step triggers execution of the attacker's embedded command. The result is OS-level code execution with the privileges of the Flowise process, which in containerized deployments often means root access.


## Severity and Impact


| Field | Details |

|-------|---------|

| CVE ID | CVE-2026-40933 |

| CVSS Score | 9.9 (Critical) |

| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H |

| Attack Vector | Network |

| Attack Complexity | Low |

| Privileges Required | Low (any user who can create/edit chatflows) |

| User Interaction | Required (user must import malicious chatflow) |

| Scope | Changed (can affect connected systems) |

| Confidentiality Impact | High |

| Integrity Impact | High |

| Availability Impact | High |

| CWE | CWE-502 (Deserialization of Untrusted Data), CWE-78 (OS Command Injection) |


The blast radius of successful exploitation extends far beyond the Flowise process itself. According to Obsidian Security, once an attacker gains code execution, they can read every credential stored in the platform, reach every connected service, and pivot to downstream systems. In production environments—where Flowise typically integrates with databases, APIs, cloud accounts, and managed LLM services—the impact is catastrophic. A compromised Flowise instance becomes a beachhead for lateral movement within an organization's infrastructure.


## Affected Products


  • Flowise: All versions before 3.1.0
  • Flowise Cloud: Not vulnerable (stdio MCP is disabled by design)

  • Self-hosted Flowise deployments are vulnerable by default and require immediate patching.


    ## Mitigations


    Immediate Actions:


  • Upgrade Flowise to version 3.1.0 or later — This is the primary fix and should be treated as urgent.
  • Restrict chatflow import permissions — Limit which users can import or create chatflows, especially from untrusted sources. Treat chatflow imports with the same caution as code reviews.
  • Disable Custom MCP Tool functionality if it is not required for your use case. Review your current MCP configurations and remove any that are unnecessary.
  • Network segmentation — Isolate Flowise instances from sensitive backend systems and databases using network policies, VLANs, or containerization boundaries. Do not run Flowise with unnecessary cloud account credentials or database write permissions.

  • Detection and Monitoring:


  • Audit chatflow imports — Monitor Flowise logs for suspicious imports or MCP configurations that reference unusual system commands (e.g., bash, sh, curl, nc, wget).
  • Watch for MCP stdio execution — Alert on any MCP server attempts to execute system commands that deviate from expected configurations.
  • Review connected credentials — Audit which credentials and API keys are stored in Flowise and rotate any that may have been exposed.

  • Long-Term Hardening:


  • Run Flowise with least privilege — Do not run Flowise containers or processes as root. Use dedicated service accounts with minimal required permissions.
  • Assume chatflows are code — Treat all chatflow imports from external sources as untrusted. Implement code review processes for complex chatflows before deployment.
  • Monitor Anthropic MCP ecosystem updates — Similar vulnerabilities may exist in other MCP-compatible tools. Subscribe to security advisories from Anthropic and tools in your MCP supply chain.

  • ## References


  • [Obsidian Security Advisory on CVE-2026-40933](https://www.obsidiansecurity.com/)
  • [NIST National Vulnerability Database Entry for CVE-2026-40933](https://nvd.nist.gov/vuln/detail/CVE-2026-40933)
  • [Flowise GitHub Repository](https://github.com/FlowiseAI/Flowise)
  • [Anthropic MCP Protocol Documentation](https://www.anthropic.com/mcp)

  • ---


    ## HackWire Analysis


    This vulnerability exposes a fundamental friction point in the emerging AI agent ecosystem: the tension between usability and security. Flowise's core strength—allowing non-developers to compose powerful AI workflows through a visual interface—becomes its critical weakness when those workflows can embed arbitrary system commands without validation.


    The fact that this is a systemic flaw in MCP's design, not a Flowise-specific implementation bug, should concern the broader ecosystem. Anthropic designed MCP to be a standard protocol for AI agents to call external tools and services. But by allowing stdio-based MCP configurations to execute any command without strict sandboxing, the protocol inadvertently created a supply-chain vulnerability in any tool that imports MCP configurations from untrusted sources. Flowise is the canary in the coal mine.


    The timing matters: we're in the inflection point where AI agents are moving from experimental to production deployments. Organizations are wiring Flowise and similar platforms into critical business processes, databases, and cloud infrastructure. Many were built before MCP security matured, and many teams haven't yet developed governance practices for "chatflow supply chains"—the vetting and review of imported workflows the way developers vet code dependencies. When PoC code goes public (as it now has), the window for exploitation widens dramatically. Defenders at organizations running self-hosted Flowise have days, not weeks, to patch and audit their instances.


    The hidden risk: containerized Flowise deployments—the default in production—often run as root or with overprivileged service accounts. Combined with this RCE, the blast radius extends immediately to container escape, host compromise, and lateral movement into Kubernetes clusters. This isn't just a code execution bug; it's a container breakout waiting to happen for many organizations.


    Defenders should treat this as a zero-day equivalent, even though it was disclosed in April. The release of working PoC code accelerates the timeline for mass exploitation. Patch immediately, audit historical chatflow imports, and rotate any credentials accessible from your Flowise instances.


    — HackWire Editorial


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)