Langflow Fixed Its MCP Command RCE Twice. Only the Second Fix Checks Where the Command Runs.

As of September 29, 2026.

If you run Langflow and moved to 1.9.0 because of the September 10 advisory, you are still exposed. Upgrade to 1.10.3 or later. The first fix checked the command where it arrived; the second checks it where it runs, and only the second closes the bug.

Two advisories, one bug

Langflow is an open-source builder for AI agent workflows. It can connect to MCP servers, and an MCP server on the stdio transport is a local program that Langflow starts itself.

On September 10 the maintainers published GHSA-7w94-79vh-5mr2, rated critical. Any authenticated user could add an MCP server with a stdio command, and Langflow passed that command "directly to bash -c "exec {command}" with zero validation." The advisory listed 1.9.0 as the patched version.

On September 28 they published GHSA-w794-rj3p-xv45, rated 9.9 on CVSS 3.1, which says the bug "was fixed in two steps and is fully fixed in Langflow 1.10.3." It affects langflow from 1.1.2 up to 1.10.3, langflow-base up to 0.10.3, and lfx up to 1.10.3.

Both fixes shipped months before either advisory. Langflow 1.9.0 reached PyPI on April 14 and 1.10.3 on July 23. A team that followed the first advisory to the letter picked the version that still had the hole.

How the command ran

The configured command ran on the Langflow host, as the Langflow process user, "as soon as Langflow tries to connect to the server." That covers listing servers, loading tools and running a flow. The process starts before any MCP handshake, so it runs "even when the UI then reports that the stdio server failed to start."

Anyone who could reach the MCP server settings page, call POST /api/v2/mcp/servers/{server_name}, or build a flow with the MCP Tools component could set that command. A default widened who that was. With LANGFLOW_AUTO_LOGIN=true, GET /api/v1/auto_login "hands out a token without credentials," so an exposed instance in its default configuration needed no account at all. The setting is documented as development-only; with it off, any authenticated user who is not an admin can still exploit the bug.

Why the first fix missed

Version 1.9.0 (PR 12290) added a command allowlist and checks on arguments and environment variables to MCPServerConfig, the model behind the REST endpoint. That blocked the route in the report.

It did not touch the code that starts the process. The advisory puts it plainly: in 1.9.0 through 1.10.2 "the execution sink still has no validation and still uses bash -c." A config that never passed through the REST model still ran: an MCP Tools component value saved inside a flow, or one passed as a tweak, Langflow's per-run override of a component's settings.

Version 1.10.3 (PR 14036) moved the policy into one function, validate_mcp_stdio_config, and enforces it at the API, at flow execution, in the deprecated MCP Stdio component, and right before the process spawns. It also dropped the shell. The command string is split into a program and arguments and started directly, so shell metacharacters mean nothing.

Check at the sink

Agent tools invite this bug, because one dangerous action is reachable from many doors. In Langflow the same "start this program" step sat behind a settings page, a REST API, a saved flow, a tweak and an old component. A check on each door covers the doors someone listed. A check at the sink, the line that starts the process, also covers the door added next quarter.

The door checks still earn their place. They reject a bad config early, with a clear error, before it is saved where the next user will load it. The sink check is the one that has to be right.

The same reasoning applies outside Langflow. Any agent framework that turns configuration into a running program, which is what the stdio transport does, carries this risk; we covered the protocol-level version of it in April.

What to do now

1. Check your version. Run pip show langflow, or check the image tag. Anything below 1.10.3 is affected, including 1.9.x.
2. Upgrade to 1.10.3 or later. If you upgraded for the September 10 advisory and stopped at 1.9.x, upgrade again.
3. Turn off auto-login on anything reachable from a network. Set LANGFLOW_AUTO_LOGIN=false, and do not expose Langflow directly to untrusted networks. These are the advisory's workarounds if you cannot upgrade yet.
4. Limit accounts. Until you upgrade, any account can run commands on the host. Give accounts only to people you would give a shell.
5. Pin the packages MCP servers may run. The 1.10.3 allowlist still permits npx and uvx, and those will fetch and run any package. On shared deployments the advisory recommends setting LANGFLOW_MCP_SERVER_ALLOWED_PACKAGES to the packages you mean to run.
6. Look for signs of use on exposed instances. Review stored MCP server configs and saved flows for stdio commands you do not recognize, and check the host for files, processes and outbound connections that the Langflow user should not have. Our MCP server review checklist covers what else to audit.