| Package | Affected versions | Patched versions |
|---|---|---|
| langflow | ≥ 1.1.2, < 1.10.3 | 1.10.3 |
| langflow-base | ≥ 0.1.2, < 0.10.3 | 0.10.3 |
| lfx | < 1.10.3 | 1.10.3 |
Before Langflow 1.10.3, the MCP stdio transport launched whatever command / args a user put in an MCP server configuration, with no allowlist and (before 1.10.3) wrapped in bash -c "exec {command} ...". Any user able to reach the MCP server settings ("Settings → MCP Servers → Add MCP Server", POST/PATCH /api/v2/mcp/servers/{server_name}) or to build a flow with the MCP Tools component could add a "server" whose command is an arbitrary OS command (touch, rm -rf, a reverse shell, ...). The command runs on the Langflow host as the Langflow process user as soon as Langflow tries to connect to the server (listing servers, loading tools, running the flow) — even when the UI then reports that the stdio server failed to start.
With the default LANGFLOW_AUTO_LOGIN=true, GET /api/v1/auto_login hands out a token without credentials, so on an exposed instance running the default configuration this is reachable without an account. AUTO_LOGIN is documented as a development-only setting; with it disabled, any authenticated (non-admin) user can exploit it.
The issue was fixed in two steps and is fully fixed in Langflow 1.10.3 (and 1.11.0+):
MCPServerConfig), blocking the "Add MCP Server" vector reported here.lfx.base.mcp.util), including configs embedded in flows / tweaks and the final pre-spawn boundary, and removed the bash -c wrapper (the process is now exec'd directly, without a shell).| Package (PyPI) | Vulnerable | Patched |
|---|---|---|
langflow | >= 1.1.2, < 1.10.3 | 1.10.3 |
langflow-base | >= 0.1.2, < 0.10.3 | 0.10.3 |
lfx | < 1.10.3 | 1.10.3 |
| Release | State |
|---|---|
1.1.2 – 1.4.x | MCP Stdio component (added in #5148) runs StdioServerParameters(command=..., args=...) from the component's command field with no validation. |
1.5.0 – 1.8.x | "Add MCP Server" settings page and /api/v2/mcp/servers API added (#8388). Stored stdio configs are launched via bash -c "exec {command_str} ..." with no validation. The PoC below works as-is. |
1.9.0 – 1.10.2 | #12290: POST/PATCH /api/v2/mcp/servers reject commands outside the allowlist. The execution sink still has no validation and still uses bash -c, so configs that do not go through MCPServerConfig (for example an MCP Tools component value embedded in a flow or passed as a tweak) can still execute arbitrary commands. |
1.10.3+ | #14036: one shared policy (lfx.base.mcp.security.validate_mcp_stdio_config) is enforced at the API, at flow execution and right before the process is spawned; no shell is used. Fixed. |
Vulnerable sink (src/lfx/src/lfx/base/mcp/util.py, MCPStdioClient._connect_to_server, before 1.10.3):
server_params = StdioServerParameters(
command="bash",
args=["-c", f"exec {command_str} || echo 'Command failed with exit code $?' >&2"],
env=env_data,
)
command_str is built from the user's command + args. The only "validation" before 1.9.0 was _validate_node_installation, which only checks that Node.js is installed when the command contains npx. The MCP SDK then starts the process with anyio.open_process, so the command runs before any MCP handshake — which is why it executes even if the UI shows "failed to start".
In "Add MCP Server" → STDIO, add:
Name - Test
Command - touch
Arguments - /tmp/pwn
Or through the API, using a token from auto_login (default configuration):
TOKEN=$(curl -s http://127.0.0.1:7860/api/v1/auto_login | python3 -c 'import sys,json;print(json.load(sys.stdin)["access_token"])')
curl -s -X POST 'http://127.0.0.1:7860/api/v2/mcp/servers/testing' \
-H "Authorization: Bearer $TOKEN" \
-H 'Content-Type: application/json' \
--data-raw '{"command":"touch","args":["/tmp/pwned_langflow"]}'
/tmp/pwned_langflow gets created on the server. On 1.10.3+ the request is rejected with Command 'touch' is not allowed for security reasons. Allowed commands: bash, cmd, docker, node, npx, python, python3, uvx, and the same payload fails at the sink (MCPStdioClient.connect_to_server("touch /tmp/pwned_langflow") raises MCPStdioSecurityError, and no file is created). Wrappers such as bash -c "touch ...", sh -c ..., python3 -c ... and node -e ... are also rejected.
MCPServerConfig validators: command allowlist (node, python, python3, npx, uvx, docker, and cmd/sh/bash only to wrap one of those), shell-metacharacter and dangerous-keyword checks on arguments, env var blocklist (LD_PRELOAD, NODE_OPTIONS, PYTHONPATH, BASH_ENV, ...), and Docker isolation checks.lfx.base.mcp.security.validate_mcp_stdio_config and enforces it at every entry point (API, embedded flow / tweak configs, the deprecated MCP Stdio component and just before spawn); it also launches the process without a shell:command_parts = shlex.split(command_str)
command, args = command_parts[0], command_parts[1:]
validate_mcp_stdio_config(command, args, env) # final pre-spawn enforcement
server_params = StdioServerParameters(command=command, args=final_args, env=env_data)
Later hardening (1.11.0, #13530) adds optional stricter modes for multi-tenant deployments.
LANGFLOW_AUTO_LOGIN=false and do not expose Langflow directly to untrusted networks.The allowlist still lets npx / uvx run any package by default, which is how MCP servers are normally distributed. On multi-tenant deployments, operators should also set:
LANGFLOW_MCP_SERVER_ALLOWED_PACKAGES — the exact packages npx / uvx may run.LANGFLOW_MCP_SERVER_INTERPRETER_HARDENING=true and LANGFLOW_MCP_SERVER_DOCKER_HARDENING=true.LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false, LANGFLOW_CUSTOM_COMPONENT_ADMIN_ONLY=true or LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true) also limits MCP stdio servers to superusers.Remote code execution on the Langflow host as the Langflow process user (CWE-78). Any exposed instance on a vulnerable version is affected, whether the attacker has an account or uses the default AUTO_LOGIN. The reporter found several internet-facing Langflow servers that were vulnerable.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free