CVE-2025-8943

What it actually does

Flowise versions before 3.0.1 allow the Custom MCPs feature to start local MCP servers by executing operating-system commands such as package runners and interpreters. Because default installations before the fix may run without authentication unless explicitly configured, and because the authorization model does not enforce granular RBAC around this capability, a remote network attacker can reach the Flowise service and cause it to execute unsandboxed commands in the context of the Flowise process. Successful exploitation can provide arbitrary command execution, access to application secrets, modification of Flowise data and workflows, installation of additional tooling, and potential movement to other systems reachable from the host.

Why it matters to the business

This is a critical remote command execution issue with weaponized exploitation and a high EPSS score, meaning exposed Flowise instances are attractive targets even though the issue is not currently listed in CISA KEV. A compromised instance could expose AI workflow data, API keys, model/provider credentials, internal integration tokens, and any data accessible to the Flowise runtime. Operationally, attackers could disrupt automation pipelines, alter workflows, pivot into connected services, deploy cryptominers or backdoors, and create incident response, legal, and customer-trust impacts. Because the vulnerability has been public for more than a year, any internet-exposed or unauthenticated pre-3.0.1 deployment should be treated as high risk until patched and reviewed for compromise.

How an attack unfolds

An attacker first identifies a reachable Flowise server, commonly by scanning for exposed web interfaces or API responses associated with Flowise. If the instance is running a vulnerable version and authentication is absent or weakly configured, the attacker interacts with the Custom MCPs functionality that is intended to launch local MCP servers. Instead of using the feature only for legitimate MCP startup commands, the attacker supplies or triggers command execution that causes the Flowise backend to spawn operating-system processes under the same user account as the application. From there, the attacker typically performs reconnaissance, reads environment variables and configuration files, harvests API keys or credentials, downloads follow-on tooling, establishes persistence, and may pivot to connected databases, cloud services, source repositories, or internal APIs used by Flowise workflows.

How to fix it

Upgrade Flowise to version 3.0.1 or later, or deploy a build that includes fix commit 7c803f4e0bd9e7a794a4ef2a2b45e58adff61a50. Do not leave Flowise exposed without authentication; require strong authentication for all administrative and workflow-management functions. Restrict network access to Flowise using VPN, private networking, firewall rules, reverse-proxy access controls, or identity-aware proxy controls. Disable or tightly restrict Custom MCPs where not required, and avoid allowing arbitrary command definitions from untrusted users. Run Flowise as a dedicated low-privilege operating-system user, inside a container or sandbox with minimal filesystem, network, and secret access. Rotate credentials that were accessible to vulnerable Flowise instances, including LLM provider keys, integration API tokens, database credentials, webhook secrets, and cloud credentials. Review workflow definitions, MCP configurations, and installed packages for unauthorized changes after patching.

How to confirm the fix worked

Confirm the running Flowise version is 3.0.1 or later, or verify the deployed source includes commit 7c803f4e0bd9e7a794a4ef2a2b45e58adff61a50. Validate that unauthenticated users cannot access the Flowise UI, APIs, workflow management, or Custom MCP configuration endpoints. Attempt access from an unauthenticated browser session or isolated test client and confirm requests are denied before reaching MCP-related functionality. Review deployment manifests, container images, package lockfiles, and build metadata to ensure no pre-3.0.1 image or unfixed source revision remains in use. Confirm the Flowise process runs with least privilege and cannot write to sensitive host paths or access unnecessary network destinations. If compensating controls are used, test firewall, reverse-proxy, SSO, and identity-aware proxy rules from untrusted networks.

Typical attack path

1. Scan the internet or internal network for exposed Flowise services.
2. Confirm the service is running a vulnerable pre-3.0.1 build or an unfixed commit.
3. Check whether the Flowise instance is unauthenticated or allows access to Custom MCP configuration without strong authorization.
4. Abuse Custom MCP command execution to spawn an operating-system process from the Flowise backend.
5. Run reconnaissance commands as the Flowise service account and inspect environment variables, configuration files, mounted volumes, and application data.
6. Harvest secrets such as model provider API keys, integration credentials, database URLs, and webhook tokens available to the Flowise process.
7. Deploy follow-on payloads, persistence mechanisms, reverse shells, cryptominers, or data collection scripts.
8. Use stolen credentials and network access to move laterally into connected services or exfiltrate sensitive workflow data.

How to detect it

Investigate whether Flowise application logs, reverse-proxy logs, container logs, EDR telemetry, and host process creation logs show unauthenticated access to administrative, workflow, tool, or MCP-related functions followed by new operating-system processes. Focus on Flowise processes spawning shells, package managers, download utilities, scripting runtimes, reconnaissance commands, or long-lived network connections. On Linux, review auditd, syslog, container runtime logs, shell history for the Flowise user, cron/systemd changes, temporary directories, and outbound DNS/HTTP connections. On Windows, review Security Event ID 4688, PowerShell logs, Sysmon process creation events, scheduled tasks, service creation events, and Defender/EDR alerts. Check for suspicious child processes of node, npm, npx, yarn, pnpm, or the Flowise container entrypoint. Review Flowise database or configuration storage for newly added or modified Custom MCP definitions, commands, environment variables, and workflows around the time of suspicious access. Search for evidence of secret discovery, including reads of environment files, cloud metadata endpoints, SSH keys, package registry tokens, and application configuration files. Because exploitation is weaponized and the issue has been public for an extended period, broaden the lookback to the first date the instance became exposed, not just the patch date.

• Custom MCP
• MCP Server
• npx
• node child_process
• /bin/sh -c
• /bin/bash -c
• cmd.exe /c
• powershell.exe -Command
• powershell.exe -EncodedCommand
• curl http
• curl https
• wget http
• wget https
• Invoke-WebRequest
• Invoke-Expression
• python -c
• python3 -c
• perl -e
• ruby -e
• nc -e
• ncat -e
• bash -i
• sh -i
• /dev/tcp/
• nohup
• chmod +x
• crontab -e
• /tmp/flowise
• /tmp/.flowise
• /tmp/.X11-unix
• /var/tmp/
• /etc/cron.d/
• ~/.ssh/authorized_keys
• /proc/self/environ
• /proc/1/environ
• 169.254.169.254
• FLOWISE_USERNAME
• FLOWISE_PASSWORD
• DATABASE_URL
• OPENAI_API_KEY
• ANTHROPIC_API_KEY
• AZURE_OPENAI_API_KEY
• GOOGLE_API_KEY
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

What your security team should do

• Immediately inventory all Flowise deployments, including containers, development instances, proof-of-concept servers, and internet-facing systems.
• Prioritize patching or replacing all pre-3.0.1 deployments, especially any instance reachable from the internet or lacking authentication.
• If immediate patching is not possible, remove public exposure, enforce authentication at a reverse proxy, and disable access to Custom MCP functionality until upgraded.
• Treat unauthenticated exposed vulnerable instances as potentially compromised and begin incident response triage.
• Rotate secrets available to Flowise after patching, including LLM provider keys, workflow integration tokens, database credentials, cloud credentials, and webhook secrets.
• Review Flowise workflows, MCP configurations, package dependencies, and filesystem changes for unauthorized modifications.
• Enable centralized logging for Flowise application logs, reverse-proxy access logs, process creation telemetry, DNS logs, and network egress from Flowise hosts.
• Add detections for unusual child processes spawned by the Flowise runtime, including shells, download utilities, package runners, scripting interpreters, and network tunneling tools.
• Restrict outbound network access from Flowise hosts to only required model providers, package registries, databases, and approved integrations.
• Document and enforce ownership, authentication, and network exposure standards for AI workflow orchestration tools.