Langflow: OS command injection (RCE) via arbitrary command in MCP stdio server configuration

The issue was fixed in two steps and is fully fixed in Langflow 1.10.3 (and 1.11.0+):

• 1.9.0 — #12290 added a command allowlist and argument/env validation to the REST model (MCPServerConfig), blocking the "Add MCP Server" vector reported here.
• 1.10.3 — #14036 applied the same policy at the execution sink (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).

Affected versions

Details

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".

PoC (as reported, Langflow 1.5.0 – 1.8.x)

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.

Fix

• #12290 (1.9.0) — 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.
• #14036 (1.10.3) — moves the policy into 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.

Workarounds (if you cannot upgrade)

• Set LANGFLOW_AUTO_LOGIN=false and do not expose Langflow directly to untrusted networks.
• Only give Langflow accounts to trusted users.

Hardening recommendations for 1.10.3+

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.
• On 1.11.1+ (#14150), restricting custom code (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.

Impact

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.