Langflow pipes commands into bash

CVE-2026-105740 lets any authenticated Langflow user run arbitrary commands on the host, and the cause is about as plain as RCE gets: the command field for an MCP server is passed straight into bash -c "exec {command}" with no allowlist, no sandbox, and no validation. Langflow scores it 9.9 and it affects every version before 1.9.0.

Langflow is an open-source platform for building AI applications and agentic workflows. DataStax, its parent, was acquired by IBM in February 2025.

How it works

MCP servers using the “stdio” transport run a local process and talk to it over stdin and stdout, which is normal for the protocol. Langflow stores whatever command a user supplies for that process and runs it when the server list is fetched. The path to code execution is two requests. A regular, non-admin user POSTs to /api/v2/mcp/servers/{server_name} with a command field containing something like a reverse shell, and Langflow stores it without checking anything. A GET to /api/v2/mcp/servers?action_count=true loads the list and executes the command with the privileges of the Langflow process. The env field takes arbitrary environment variables too, so LD_PRELOAD or a PATH override is available alongside the command itself.

Two properties make this worse than a single shot. The configuration persists, so the command re-runs every time the server list loads, which turns it into a backdoor that reinstalls on each read. And MCP server configs live in project settings rather than the flow editor, so they are not visible when someone reviews a flow the way custom component code is.

The campaign

Previdian reports 1,423 exploitation attempts against its honeypot sensors since September 19, 2026, from 27 unique IP addresses spread across fifteen countries including China, Russia, Germany, the U.S., and Vietnam. Activity jumped on October 11 with 333 attempts in a day, and 66 more were logged on October 15.

The flaw needs a valid session, so the interesting question is how attackers get one. Previdian founder Ryan Dewhurst described one observed sequence: the attacker checked the Langflow version, tried /api/v1/auto_login (which returned 403 because it was disabled on the honeypot), then authenticated with a common username and password and used the resulting bearer token to reach the MCP endpoint. Auto-login left on would hand them a session with no credential guessing at all.

Captured payloads line up with what you would expect from someone looting a box. Some extract environment variables and config values, including LANGFLOW_SECRET_KEY and LANGFLOW_SUPERUSER_PASSWORD, and ship them to 146.70.211[.]112:18764. Others run Docker commands to reach the host filesystem and read /etc/passwd. A lot of the traffic is just id and whoami probes confirming execution.

One address, 192.255.229[.]92, accounts for a large share of the environment-variable theft. GreyNoise and Previdian both show it running generic brute-force attacks and hitting other bugs in Flowise (CVE-2026-69255) and Langflow (CVE-2026-55255, CVE-2026-9198, CVE-2026-0768). The spread across several Langflow CVEs reads as one unknown actor working through exposed instances methodically. What they are ultimately after is not clear yet.

What to do

Upgrade to 1.9.0 or later. If you cannot patch immediately, set LANGFLOW_AUTO_LOGIN=false, keep Langflow off untrusted networks, enforce strong unique passwords, and limit accounts to people you trust, since every authenticated user is effectively a shell on the box. Review authentication logs and any requests to /api/v2/mcp/servers/ for the two-step pattern above.

Worth factoring into that decision: this is the second 9.9 in the same subsystem. Last month Langflow fixed CVE-2026-105697, another OS command injection through MCP stdio server configuration. The stdio command path has now produced two critical bugs, which is a reasonable argument for locking down who can reach it rather than trusting the next patch to be the last.