Five Langflow CVEs Show How MCP Server Settings Became a Route to Host Commands

GitHub published five CVE records for Langflow on October 5, 2026, four of them tied to its Model Context Protocol features. Two are rated 9.9 Critical for command execution through MCP stdio server configs. Fixes shipped in Langflow 1.9.0 through 1.10.3, so older self-hosted instances are the ones at risk.

Langflow agent builder with an MCP stdio server configuration flagged as a command-execution path
Langflow agent builder with an MCP stdio server configuration flagged as a command-execution path

GitHub, acting as CNA, published five CVE records for Langflow on October 5, 2026, between 20:16 and 20:56 UTC. Langflow is the open-source tool for building and deploying AI agents and workflows. Four of the five involve its Model Context Protocol (MCP) features, and two carry a CVSS 3.1 score of 9.9 (Critical) for running operating-system commands on the Langflow host. NVD listed the records at 21:16 UTC with the status Received. The fixes are not new. They shipped across Langflow 1.9.0, 1.9.1, 1.10.1, and 1.10.3, released between April and July 2026. The CVE records now give operators of older self-hosted instances a clear reason to upgrade.

A configuration field that ran commands

MCP servers using the stdio transport are local processes. A client like Langflow starts them with a command and arguments, then exchanges messages with them. According to CVE-2026-105697, before Langflow 1.10.3 the stdio transport “launched whatever command / args a user put in an MCP server configuration, with no allowlist,” wrapped in a bash -c shell. Anyone who could reach the MCP server settings, or build a flow with the MCP Tools component, could make the server run an arbitrary command as the Langflow process user. The command ran as soon as Langflow tried to connect to the server, “even when the UI then reports that the stdio server failed to start.”

The default configuration made this worse. With LANGFLOW_AUTO_LOGIN=true, the default, an auto-login endpoint hands out a token without credentials. The record says that on an exposed instance in that configuration the flaw “is reachable without an account.” Langflow documents auto-login as a development-only setting. With it turned off, any authenticated non-admin user could still exploit the flaw. The advisory adds that the reporter “found several internet-facing Langflow servers that were vulnerable.”

The companion record, CVE-2026-105740, also scored 9.9, covers the same stdio path before 1.9.0 from the angle of the settings API. It notes that the configuration’s environment field accepted arbitrary variables, including loader and path overrides such as LD_PRELOAD and PATH.

Fixed in two steps

The GitHub advisory for CVE-2026-105697 describes a two-stage fix. Langflow 1.9.0, published to PyPI on April 14, added a command allowlist and argument and environment validation to the REST model behind “Add MCP Server” (pull request #12290). That closed the settings-page route, but configurations that bypassed the model still reached the unvalidated execution sink. Examples were MCP Tools values embedded in a flow or passed as tweaks. Langflow 1.10.3, published on July 23, enforced one shared policy at the API, at flow execution, and just before the process is spawned (pull request #14036). It also dropped the shell wrapper, so the process is now executed directly. Affected ranges are langflow 1.1.2 up to 1.10.3, langflow-base 0.1.2 up to 0.10.3, and lfx before 1.10.3.

Three more MCP and access-control gaps

  • CVE-2026-105741 (CVSS 3.1: 7.1). From 1.5.0 until 1.10.3, the MCP configuration install endpoint enforced its “local-only” restriction by trusting a forwarded-for header. An authenticated attacker who spoofed that header could write or overwrite an MCP client configuration file on the server. Fixed in 1.10.3.
  • CVE-2026-105699 (CVSS 4.0: 7.1). From 1.6.8 until 1.9.1, project-scoped MCP connections authenticated the project but did not authorize the resource URI passed to resources/read. A user with access to any project-scoped MCP endpoint could read another user’s flow-backed files, including uploaded documents and prompts. Fixed in 1.9.1.
  • CVE-2026-105698 (CVSS 3.1: 5.4). From 1.0.0 until 1.10.1, deprecated flow-build endpoints did not check flow ownership. A caller who knew another user’s flow ID could load that flow and run selected parts of it. Through 1.7.1 no authentication was needed. Fixed in 1.10.1.

Hardening beyond the patch

The direct fix is to run 1.10.3 or later. PyPI lists 1.12.4 as the current release. Operators who cannot upgrade right away should set LANGFLOW_AUTO_LOGIN=false, keep Langflow off untrusted networks, and give accounts only to trusted users. The advisory also warns that the 1.10.3 allowlist still permits npx and uvx, which can fetch and run any package. For multi-tenant deployments it recommends pinning permitted packages with LANGFLOW_MCP_SERVER_ALLOWED_PACKAGES and turning on the interpreter and Docker hardening flags. On 1.11.1 and later, restricting custom components also limits MCP stdio servers to superusers.

The underlying lesson goes beyond Langflow. In any agent platform that lets users register stdio MCP servers, that settings screen is effectively a command line on the host. Access to it needs the same controls as shell access.

Topics
  • #Cybersecurity
  • #Langflow
  • #MCP
  • #CVE
  • #AI Agents
Raj M

Author

Raj M

Contributor

AI Systems Architect is a seasoned technology leader with over 15 years of experience in the IT industry working with Fortune 500 companies. With a solid foundation in multi-agent systems, open-source LLM infrastructure, and enterprise deployment, he excels at building scalable production-grade AI platforms.