· via dev.to (home feed)
Langflow CVE-2026-105740 let registered users run arbitrary bash via stdio MCP servers
Langflow's CVE-2026-105740 (CVSS 9.9) let any authenticated user register a stdio MCP server whose command ran through bash -c, and listing servers was enough to trigger it.

A critical Langflow vulnerability tracked as CVE-2026-105740, with a CVSS score of 9.9, allowed any authenticated user of an instance to register an stdio MCP server whose command string was passed straight to bash -c. According to a technical write-up on dev.to, the flaw also had an unusual trigger: simply listing the configured servers was enough to execute the payload.
How the flaw worked
Citing advisory GHSA-7w94-79vh-5mr2, the post explains that Langflow's API accepted a complete MCP server configuration — command, arguments, environment variables, URL and headers — from any logged-in user, with no validation against an allowlist or blocklist of commands.
The command was launched by spawning a shell with the -c flag and wrapping the user's string in an exec call chained to an error message. The post walks through why that wrapper is misleading. Since exec replaces the shell with the target program, the chained error handler never runs. Command substitution, by contrast, fires before exec takes over, so $(...)-style payloads execute normally.
The user-controlled environment dictionary was merged into the child process environment, which the author treats as a separate injection channel: a supplied PATH can decide which binary actually runs, and LD_PRELOAD affects any dynamically linked program on Linux.
All of that is secondary, the post argues. The core defect is that a regular user decides what code the platform executes. Even a parser that perfectly rejected command substitution would still run a fetch-and-execute pipeline typed directly into the command field.
The trigger also deserves attention: execution did not require anyone to invoke the server. A GET request to the server-listing endpoint /api/v2/mcp/servers with the action_count parameter was enough to start the command.
Versions and observed exploitation
Per the advisory, version 1.8.3 is affected and the fix shipped in 1.9.0. A triage note referenced in the post also lists 1.10.3, so the author recommends running 1.10.3 or later to be covered under either reading — worth verifying against your own deployment given the disagreement between the two sources.
Honeypots have already seen activity. The post cites exploitation-attempt reports in the low thousands, including one sensor that documents its methodology and counted 2,023 attempts since 19 September.
The durable fix: server IDs, not command strings
The write-up's proposed pattern treats MCP launches like any other dependency: users pick a server ID and never transmit a command. Each ID maps to an exact, reviewed argv with a version pinned at image build time, executed without a shell. The child environment is built from an allowlist plus administrator-set values, never merged from the request. Registering a new ID becomes an admin action with an audit trail.
The post adds that in Langflow the malicious configuration persisted inside project settings — a location that reviews of flows never examined.
The same exposure on a patched machine
The author then audited a clean development machine running Claude Code and found the risk without any vulnerability: a local-scope server entry invoking npx @playwrigth/mcp@latest — a transposed typo of playwright pointing at an npm scope that returns a 404 and a scope-not-found error. Anyone can create that organization on npm and publish the package, and because the entry resolves @latest, the next session start would run whatever was most recently published under that name.
The entry never worked, and a failed MCP connection is only a log line rather than a blocking error, which is why the typo survived unnoticed. The fix is to remove the entry and re-add the correct server with a pinned version.
The post also warns that approval prompts are not a complete defense. Claude Code asks before using project-scope servers in interactive sessions, but headless claude -p runs, Agent SDK sessions and some cloud sessions load them without asking — and local-scope entries, where the typo lived, involve no approval step at all.
Why it matters
An MCP server on stdio transport is ultimately a command executed by your agent with your own privileges, and this incident illustrates both directions of that exposure. Langflow shows how quickly a configuration API becomes remote code execution once users can define command strings; the typo-scope finding shows that a fully patched, uncompromised machine can still sit one npm registration away from executing attacker code at the next startup. For teams adopting agentic tooling, pinning server commands to reviewed specs, auditing the config files agents read, and verifying that referenced packages actually exist are now baseline hygiene rather than optional hardening.
- #langflow
- #mcp
- #security
- #vulnerability
- #ai-agents