Decoding the world of cybersecurity

Flowise RCE shows AI builder risk

A critical Flowise vulnerability shows how self-hosted AI builder tools can become infrastructure exposure through connectors, credentials, workflow imports, and server-side execution.

Flowise RCE shows AI builder risk
Summary
  • A GitHub advisory lists CVE-2026-40933 as a critical authenticated RCE affecting Flowise and flowise-components versions up to 3.0.13.
  • The flaw involves unsafe serialisation of stdio commands in the MCP adapter, with version 3.1.0 listed as patched.
  • AI workflow platforms can hold credentials, integrations, and access to cloud or SaaS systems, making ordinary application flaws more consequential.

Flowise, an open-source platform for building AI agents and large language model workflows, has a critical remote code execution vulnerability in self-hosted deployments, showing how AI builder platforms are becoming part of enterprise infrastructure risk.

The GitHub advisory for CVE-2026-40933 describes an authenticated remote code execution flaw in Flowise’s Model Context Protocol adapter. It affects the flowise and flowise-components npm packages in versions up to and including 3.0.13. Version 3.1.0 is listed as the patched release.

The flaw sits in the handling of stdio commands in MCP configuration. According to the advisory, an authenticated attacker can add an MCP stdio server with an arbitrary command, achieving command execution. The advisory describes unsafe serialisation in the MCP adapter and says input sanitisation checks can be bypassed through permitted command patterns.

Obsidian Security has also described a one-click attack path in which a malicious chatflow import could trigger server-side execution before a user saves or runs the workflow. Obsidian says Flowise Cloud is not affected because stdio MCP is disabled, while self-hosted open-source and enterprise deployments are vulnerable by default in the scenario it describes.

A server-side command execution flaw in a workflow builder can expose the host environment, application secrets, API keys, stored credentials, and connected systems. AI orchestration platforms are often introduced quickly because they accelerate experimentation, but that speed can leave security ownership unclear once the platform is connected to real systems.

AI builder tools are not only development utilities when they connect to internal services. They can sit near databases, document stores, customer-support systems, cloud accounts, SaaS APIs, retrieval pipelines, and automation workflows. A flaw in that layer can cross from model experimentation into business process compromise.

The MCP element is important because Model Context Protocol is becoming a common way to connect AI systems to tools and data sources. Some MCP configurations are designed to launch local processes or interact with external services. Where a feature legitimately executes commands or connects tools, controls need to define who can configure it, what it can reach, and how execution is constrained.

Traditional application-security programmes may not yet have full visibility of these platforms. A self-hosted AI workflow tool might be installed by an innovation team, platform engineering group, or business unit outside the normal production software inventory. If it then receives real credentials or connects to live services, the organisation has created infrastructure without the surrounding governance usually applied to infrastructure.

The response should begin with version and deployment discovery. Organisations using Flowise should identify self-hosted instances, confirm whether affected versions are present, restrict access to trusted administrators, review chatflow import practices, and assess whether MCP stdio functionality is required. Where credentials were stored or accessible from the host, rotation and access review may be necessary if compromise cannot be ruled out.

AI security cannot remain focused only on prompts, models, and data leakage. Builder platforms, connectors, workflow imports, plug-ins, registries, and runtime permissions are becoming the practical attack surface. Security controls need to follow the system that executes actions, especially as AI agents are connected to more enterprise systems.

The Flowise advisory gives a concrete example of ordinary application risk inside AI workflow tooling. The vulnerability is server-side code execution in software used to build AI workflows. As those tools gain access to more data and services, the builder becomes infrastructure, and infrastructure needs the same discipline as any other privileged platform.

×