Track vulnerabilities like this one. Sign up free to get alerted when software you use is affected.
9.9

CVE-2026-105697: Langflow lets attackers run any command on server

CVE-2026-105697 · published 2 days ago
Summary

Versions of Langflow before 1.10.3 let anyone who can add or edit an MCP server configuration cause the application to execute arbitrary operating‑system commands. The flaw can be triggered without a password when the default auto‑login setting is left on, allowing an attacker to run commands such as file deletion or a reverse shell on the host running Langflow. Upgrade to Langflow 1.10.3 or later and disable the auto‑login feature to close the risk.

What to do
  • Update langflow to version 1.10.3.
  • Update langflow-base to version 0.10.3.
  • Update lfx to version 1.10.3.
Affected software
Ecosystem VendorProductAffected versions
– langflow-ai langflow >= 1.1.2, < 1.10.3
– langflow-ai langflow-base >= 0.1.2, < 0.10.3
– langflow-ai lfx < 1.10.3
pip – langflow >= 1.1.2, < 1.10.3
Fix: upgrade to 1.10.3
pip – langflow-base >= 0.1.2, < 0.10.3
Fix: upgrade to 0.10.3
pip – lfx < 1.10.3
Fix: upgrade to 1.10.3
Original advisory text
Langflow: OS command injection (RCE) via arbitrary command in MCP stdio server configuration
### Summary

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+):

- **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

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

### Details

Vulnerable sink (`src/lfx/src/lfx/base/mcp/util.py`, `MCPStdioClient._connect_to_server`, before 1.10.3):

```python
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):

```bash
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:

```python
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.
Fix within
Internet-facing 14 days
Internal At next upgrade
  • Not known to be exploited
  • Needs hands-on effort to exploit
  • Gives an attacker full control
Severity
9.9 Critical
Exploitation
<1% chance of attack within 30 days
Type
CWE-78OS Command Injection
Timeline
Published7 Oct 2026
Updated10 Oct 2026
First seen5 Oct 2026
Track software like this
Free during beta