Flowise servers used to build AI agents and automated workflows are facing six newly disclosed remote code execution flaws.
The weaknesses could allow authenticated attackers to run commands on the underlying server, putting data, credentials, and connected systems at risk.
The attack paths involve several Flowise components, including CSV processing, custom JavaScript functions, MCP configurations, database nodes, and record-management features.
The findings add to concerns raised by previous Flowise injection exploitation, where exposed AI workflow servers became attractive targets for attackers.
Researchers at Elttam identified the issues while reviewing Flowise versions 3.1.1 and 3.1.2.
Elttam said in a report shared with Cyber Security News (CSN) that several fixes were incomplete, allowing researchers to find new ways around earlier security controls.
The overall impact can be serious because Flowise often connects language models to business tools, files, databases, and external services.
A successful compromise could give an attacker a foothold on the workflow host and access to the resources available to that server.
Six Flowise RCE Flaws
The first issue affected the CSVAgent feature, which lets users provide custom pandas code to process uploaded CSV files.
Although Flowise used a denylist to block risky Python functions, the researchers found ways to abuse pandas functionality and execute commands outside the intended data-processing task.
An initial patch attempted to block unsafe deserialization and require input to begin with read_csv.
However, Elttam found that a crafted expression could still meet those restrictions while accessing operating-system functionality through pandas.
The developers later removed the affected CSVAgent and AirtableAgent files after identifying normalization concerns.
A second flaw involved Flowise’s use of the vm2 JavaScript sandbox. The sandbox allowed certain external modules by default, including moment, and researchers used that access to escape the restricted environment and execute code on the host.
This reinforces the risks described in critical Flowise MCP weakness, where insecure integration settings can defeat assumed protections.
The report also described an environment-variable injection issue in Custom MCP configurations. Attackers could abuse settings passed to a spawned process, including Python-related variables, to trigger execution.
While Flowise introduced checks for dangerous values, researchers said they found a bypass that remained unpatched when the report was published.
Three other issues were found in the TypeORM DataSource options, SQL Database Chain node, and SQLite Record Manager node.
Each could be used to write or load attacker-controlled content in unsafe ways, potentially leading to code execution when combined with other Flowise functions.
Hardening AI Workflow Servers
The findings show why AI workflow infrastructure needs the same defensive attention as any internet-facing application.
MCP integrations can extend an agent’s capabilities, but they can also create dangerous trust paths, as shown in research on MCP server execution risks.
Administrators should update Flowise promptly, review all deployed nodes, and remove or disable components that are not required.
They should also avoid exposing administrative interfaces and APIs directly to the public internet, especially where workflow users can submit code, configuration data, files, or database connection details.
Organizations should treat MCP server settings as untrusted input and limit the permissions available to AI workflow processes.
Running Flowise with a non-root account, isolating it in a restricted environment, and closely controlling file-system access can reduce the damage if a bug is exploited.
Security teams should monitor for unexpected child processes, suspicious outbound connections, changes to workflow configurations, and unusual file uploads.
.webp)
They should also restrict external MCP servers to verified sources and require review before new integrations are enabled, since malicious MCP prompt attacks can turn trusted automation into an attack route.
Elttam recommended moving away from vm2 toward a stronger isolation model and avoiding reliance on denylist-based validation for dangerous inputs.
The report also stressed that allowlists, secure defaults, and separation of untrusted code from the host environment are more reliable protections for workflow platforms.
Indicators of Compromise (IoCs):-
| Type | Indicator | Description |
|---|---|---|
| IP address | 172.17.0.1 | Private Docker-network address used in proof-of-concept reverse-shell payloads. |
| IP address | 192.168.122.62 | Private laboratory address shown in proof-of-concept HTTP requests and URL injection examples. |
| IP address | 0.0.0.0 | Bind address used in the proof-of-concept Python HTTP server. |
| Hostname | localhost | Local host used in the Flowise prediction endpoint proof of concept. |
| URL | http://localhost:3000/api/v1/prediction/UUID | Local Flowise endpoint shown for triggering a vulnerable chatflow. |
| API endpoint | POST /api/v1/node-custom-function | Flowise endpoint used to execute custom JavaScript functions in the vm2 sandbox scenario. |
| API endpoint | POST /api/v1/auth/login | Flowise authentication endpoint referenced in the proof of concept. |
| API endpoint | POST /api/v1/document-store/loader/process/:loaderId | Flowise document-store endpoint referenced after uploading a JavaScript payload. |
| File name | rce.js | JavaScript reverse-shell payload file used in the researchers’ demonstration. |
| File path | /root/.flowise/storage/ | Default local Flowise storage path referenced in the proof of concept. |
| File path | /etc/chromium/exploit.conf | File path used in the SQL Database Chain and Chromium execution demonstration. |
| File path | /proc/self/environ | Linux process environment path used in an MCP configuration bypass demonstration. |
| File path | /root/.flowise/database.sqlite | Default Flowise SQLite database path referenced by the researchers. |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Building Resilience Against Phishing & Malware and Analyze it in a safe environment – Power your SOC with ANY.RUN

