Published: 2026-10-16

Langflow MCP flaw under active exploitation: why the 'command' field in an MCP configuration is executable code

Q: What is the difference between stdio and HTTP for this risk?

With stdio the client itself starts a local process from command and args in the configuration, so the configuration is executable code. With HTTP (remote MCP servers) the client only connects to a URL and no process is started. For business users in a platform, HTTP with OAuth is therefore the safer default; stdio belongs on developer machines with trusted configuration.

In short: attackers have exploited a critical Langflow flaw (CVSS 9.9) since 19 September 2026: the command field of an MCP server configuration ran unchecked as a shell command. On 15 October JetBrains published a CVE for the same pattern in Junie CLI. Lesson: whoever may add an MCP server may execute code. Fixed in Langflow 1.10.3 and Junie CLI 26.8.3.

An MCP client can talk to a server in two ways: over HTTP to a URL, or over stdio, where the client itself starts a local process from a command and args in the configuration. Every product that lets users define such a stdio server is also deciding who may start processes. This week two advisories show what happens when that decision is not made consciously.

What happened at Langflow?

Langflow is an open-source platform for building AI agents and workflows visually, originally from DataStax, whose acquisition IBM announced in 2025. The project published two advisories about the same feature.

CVE-2026-105740 (advisory 10 September, CVE record 5 October, CVSS 9.9). Before version 1.9.0 any logged-in user, including non-admins, could add an MCP server with the stdio transport. The command field was passed without any check to bash -c "exec {command}" and ran as soon as the server list was fetched; the env field also allowed manipulation of variables such as PATH. The fix in 1.9.0 (14 April) added an allowlist of six executables.
CVE-2026-105697 (reported by OX Security, advisory 7 October, CVSS 9.9). The same feature remained exploitable in 1.1.2 through 1.10.2; only 1.10.3 (23 July) closes it with stricter rules: a single executable in command, options only in args, no Docker host mounts or custom package sources, and local stdio servers for administrators only once code execution is locked down. An extra sting: with the default setting LANGFLOW_AUTO_LOGIN=true, documented as development-only, an internet-facing instance can be reached without an account.

The exploitation is not theoretical. Previdian's sensors saw the first attempt on 19 September; through 16 October they counted 1,751 attempts from 28 IP addresses in 16 countries, jumping to more than 300 a day from 11 October. According to The Hacker News the attackers first try auto_login, otherwise log in with a common username and password combination, and immediately use the token against the MCP endpoint. The payloads send LANGFLOW_SECRET_KEY and LANGFLOW_SUPERUSER_PASSWORD to an external address and try to read the host file system through Docker. Neither flaw is on CISA's KEV list yet, but Langflow has been listed there with six other vulnerabilities since May 2025: the platform is a standing target.

Why is this a pattern rather than an incident?

On 15 October JetBrains published CVE-2026-111091: in Junie CLI, the command-line version of its AI coding agent, code execution was possible before 26.8.3 through the MCP server configuration of an untrusted project (CVSS 7.8; local, requires a user to open the project). Since release 26.10.5 of 6 October, Junie explicitly asks at start-up whether a project is trusted.

That is the same mechanism as CurXecute (CVE-2025-54135, CVSS 8.6) in Cursor, where a prompt injection in July 2025 rewrote the mcp.json file and started the new server without confirmation. And it is the core of the advisory OX Security published on 15 April 2026: 17 products in four families, 15 of them critical, including Flowise (CVE-2026-40933, CVSS 10: the built-in list of safe commands could be bypassed), LiteLLM (CVE-2026-30623) and Windsurf (CVE-2026-30615: attacker-controlled HTML modified the local MCP configuration and registered a malicious stdio server without further interaction). Thirteen vendors told OX they would not patch. According to OX, Anthropic regards the stdio model as expected behaviour and places responsibility for input validation with the product builder.

So two trust boundaries are at play. In platforms such as Langflow and Flowise, business users define servers in a web interface, and a configuration field becomes a command on the server. In developer tools such as Junie, Cursor and Windsurf, the configuration travels with the repository or is written by the agent itself, and opening a project becomes running code.

Our advice

(1) Patch: Langflow to 1.10.3 or later (the latest is 1.12.6), disable LANGFLOW_AUTO_LOGIN outside development and take instances off the public internet; Junie CLI to 26.8.3 or later; Flowise to 3.1.0 or later. (2) Treat "add MCP server" as an administrator right equivalent to "run code on the server". Disable stdio in platforms for regular users and let business users connect to remote servers over HTTP with OAuth. (3) Treat MCP configuration in repositories as code: review it in the pull request, trust projects only after inspection, and do not let CI agents load configuration from untrusted branches. (4) No secrets in configuration files. Hush Security found in 82,000 public MCP configurations that 12% of credential slots hold a real secret, 24% of which are broad in scope and never expire. (5) Check platform accounts for default passwords: that is how the attackers got in. More in security & watchouts and, if you build your own, build an MCP server.

What does this mean when choosing MCP tooling?

Our take: the protocol is not broken here. A client starting a local process is exactly what stdio is meant to do, and on a developer's laptop that is workable. The problem arises when a product hands that building block to users who are not allowed to run code, and in low-code agent platforms that is the default user. Anyone evaluating such a platform should therefore ask four questions: who may define MCP servers, which transports are open, is there an allowlist that also covers args and package sources, and does the server run in a sandbox? This article follows our earlier pieces on SSRF through MCP servers and the advisories for the official SDKs: the ecosystem patches quickly, but responsibility for the edges lies with whoever deploys the product. See also our MCP servers for software development.

Sources

Frequently asked questions

Which Langflow version is safe?

Langflow 1.10.3 or later (the latest is 1.12.6). Version 1.9.0 closed the first flaw (CVE-2026-105740) with an allowlist, but only 1.10.3 also closes CVE-2026-105697. In addition, disable LANGFLOW_AUTO_LOGIN outside development, keep the instance off the public internet and check that no unknown MCP servers sit in the project settings: they do not appear in the flow editor and are easy to miss in a normal review.

Am I affected if I do not use Langflow or Junie?

Possibly. In April 2026 OX Security counted seventeen products with the same pattern, including Flowise (safe from 3.1.0), LiteLLM and Windsurf; Cursor had it in 2025. Check every product that lets users define MCP servers over stdio: who is allowed to, is the command field restricted to an allowlist that also covers args, and does the process run in a sandbox?

What is the difference between stdio and HTTP for this risk?

With stdio the client itself starts a local process from command and args in the configuration, so the configuration is executable code. With HTTP (remote MCP servers) the client only connects to a URL and no process is started. For business users in a platform, HTTP with OAuth is therefore the safer default; stdio belongs on developer machines with trusted configuration.

Last updated: 2026-10-16