Six newly disclosed vulnerabilities in Flowise, a popular open‑source platform for building AI agents and LLM workflows, allow unauthenticated and low‑privileged attackers to achieve remote code execution (RCE) on self‑hosted and cloud AI workflow servers running vulnerable versions.
These flaws collectively expose organizations to full server compromise, data exfiltration, and AI pipeline manipulation if instances are not promptly upgraded and locked down.
However, its GitHub security advisories already showed a history of high and critical issues, including account takeover via an insecure password reset flow (CVE‑2025‑58434) and multiple instances of user‑supplied input being executed as raw JavaScript (CVE‑2025‑59434, CVE‑2025‑59528, GHSA‑7944‑7c6r‑55vv).
Flowise’s custom Model Context Protocol (MCP) node has also been linked to prior RCE issues such as CVE‑2026‑40933, CVE‑2026‑41268, CVE‑2025‑59528 and GHSA‑6933‑jpx5‑q87q, highlighting a systemic pattern of unsafe sandboxing in AI tooling.
Researchers reviewing the Flowise 3.1.1 and 3.1.2 codebase identified six additional RCE vectors, several of which bypassed existing patches or reused insecure design patterns.
Notably, one of the new bugs overlapped with CVE‑2026‑41264, an RCE in the CSVAgent node that Flowise had already patched in earlier versions, proving that the original remediation was incomplete and remained exploitable in later builds.
The new flaws span Python, JavaScript and environment‑variable abuse, and in many cases require nothing more than user‑controlled configuration fields that were assumed safe in normal workflow construction.
One of the most critical findings is a server‑side Python execution path via the CSVAgent node, which uses Pyodide to run user‑supplied pandas code intended for CSV preprocessing.
While Flowise attempted to protect this feature with a denylist‑based validator and a requirement that code start with a single readcsv call, the researchers showed multiple ways to bypass these controls, including exploiting pandas’ readpickle to deserialize a malicious payload and using pandas.io.common.
In a practical exploit, an attacker could build a base64‑encoded pickle payload that launches a reverse shell (e.g., via nc) and deliver it through the CSVAgent “Additional Parameters” field, then trigger the chatflow via the prediction API to gain full RCE on the Flowise server.
Another class of RCE arises from Flowise’s fork of the deprecated vm2 sandbox, used to execute “Custom Function” JavaScript via the /api/v1/node-custom-function endpoint.
Elttam Researchers said that, Flowise has rapidly grown into a top GitHub project for assembling AI workflows, offering both self‑hosted deployments and a commercial cloud/enterprise tier with multi‑workspace support.
Six Flowise Vulnerabilities
Although Flowise restricted the sandbox to certain modules, it explicitly allowed axios, moment and node‑fetch, and was running a vm2 build still vulnerable to CVE‑2026‑22709, enabling a direct sandbox escape using crafted Error stack abuse and child_process.execSync.
Even after Flowise attempted to harden the sandbox and later disabled vm2 by default, the researchers demonstrated a new escape by abusing moment’s CVE‑2022‑24785 path traversal behavior inside the sandbox, combined with the Flowise document store uploader to write a JavaScript payload (rce.js) into .flowise/storage and then load and execute it via moment.
Follow‑up work showed that vm2 remained reachable even when nominally disabled, via nodes such as AgentAsTool, ChatflowTool and ExecuteFlow that invoked executeJavaScriptCode with useSandbox=false.
In these nodes, a baseURL parameter passed only a superficial isValidURL check that ignored the URL fragment, allowing attackers to inject arbitrary JavaScript into the sandboxed code by appending payloads in the hash portion.
This technique confirmed that the moment‑based sandbox escape persisted in a later Flowise commit, undermining the initial assumption that simply updating vm2 would neutralize the issue.
The sixth major RCE vector targets Flowise’s custom MCP node, which integrates external Model Context Protocol servers via the modelcontextprotocolsdk and, by default, permits the unsafe stdio transport when CUSTOMMCPPROTOCOL=stdio.
Flowise attempted to defend against local file and environment abuse with checks that restrict commands to node, npx, python, python3 and docker and denylist a few dangerous environment variables such as PATH and NODEOPTIONS, but left other powerful variables untouched.
By leveraging techniques from prior environment variable exploitation research, including joern’s PYTHONWARNINGS/BROWSER trick.
The researchers achieved RCE via python3 MCP servers and also by using node with args pointing to /proc/self/environ while overriding HOME so that the environment file becomes valid JavaScript containing a reverse shell payload.
Flowise addressed portions of these issues in multiple pull requests, including removing the CSVAgent and AirtableAgent nodes due to NFKC normalization problems, dropping moment from allowed vm2 dependencies, and adding an environment variable allowlist plus changing the default MCP transport from stdio to SSE.
However, the researchers stress that relying on vm2 remains dangerous given its history of fresh escape techniques, and recommend migrating to isolated‑vm or a stronger isolation primitive, especially for multitenant AI workflow deployments.
Administrators should immediately upgrade Flowise to the latest secure version, audit deployments for exposed prediction and node‑custom‑function endpoints, disable or lock down custom Python/JS execution nodes, and avoid enabling CUSTOMMCPPROTOCOL=stdio unless absolutely required and constrained by strict network and host hardening.
$1M Data Breach Warranty is Genuine Protection?: Download 10 Point Free AI SOC Breach Warranty Guide
