Langflow MCP flaw draws 1,400+ exploit attempts — and the first fix, 1.9.0, was incomplete

Attackers are trying to exploit a critical flaw in Langflow, the open-source tool for building AI agents and workflows, that lets any logged-in user run commands on the server through its MCP settings. Security firm Previdian says its honeypot recorded more than 1,400 attempts between September 19 and October 15, 2026. If you run Langflow, upgrade to 1.10.3 or later — not just 1.9.0, which Langflow's own advisory says left the dangerous code path open — and turn off auto-login.

What happened, in plain English

Langflow is a visual "drag-and-drop" builder for AI applications: teams wire together language models, data sources and tools on a canvas, then run the result as an agent or chatbot. It is open source and widely self-hosted.

One of the things Langflow can connect to is an MCP server. MCP (Model Context Protocol) is a standard way to give an AI agent access to tools — a file reader, a database, a search API. One way to connect an MCP server, called the "stdio" transport, works by having Langflow start a program on its own machine and talk to it.

The problem: Langflow let users type in which program to start, and ran it through the system shell without checking what it was. So anyone who could open the MCP settings could make the server run any command they liked. It is a bit like a company letting any employee add an entry to the "programs that start when the office computer boots" list — and never looking at what was added.

Two things make this worse. First, the bad entry is saved in the project and re-runs every time the server list loads, including when an administrator looks at it. Second, Langflow's "auto-login" setting, which is on by default when you install it as a Python package, signs every visitor in automatically. On an instance exposed to the internet, Langflow's advisory says, the flaw could then be reached without an account at all.

Are you affected? What to do now

Who is affected

• Self-hosted Langflow (the langflow, langflow-base or lfx Python packages) before 1.10.3 (langflow-base before 0.10.3), according to GHSA-w794-rj3p-xv45. The affected range starts at 1.1.2.
• Highest risk: instances reachable from the internet or a broad internal network, instances with auto-login on, and instances where many people have accounts.
• If you don't run Langflow — or run it only on your own laptop, bound to localhost — you have nothing urgent to do.

How to check

• Find your version: pip show langflow in the environment where it runs, or check the image tag of your container.
• Check whether auto-login is on: look for LANGFLOW_AUTO_LOGIN in your environment or .env file. If it is unset in a pip-based install, it defaults to True. Per Langflow's documentation, the official Docker images set it to false.
• Check exposure: is the Langflow port reachable from outside your network, without a login proxy in front?

What to do, in order

1. Upgrade to 1.10.3 or later (the current release line is 1.12). Do not stop at 1.9.0: the advisory says 1.9.0 added validation at the API layer but the place where the command actually runs stayed unprotected until 1.10.3.
2. Turn off auto-login: set LANGFLOW_AUTO_LOGIN=False and a strong LANGFLOW_SUPERUSER_PASSWORD. Langflow's docs also suggest disabling open sign-up (LANGFLOW_ENABLE_SIGNUP=False).
3. Take it off the open internet: put Langflow behind a VPN or an authenticating reverse proxy, and limit accounts to people who need them.
4. Review saved MCP server configurations in every project for stdio servers you don't recognise. Because a malicious entry persists, upgrading alone does not prove nobody got in earlier.
5. If the instance was exposed and unpatched, treat it as possibly compromised: look for unexpected shell processes started by the Langflow process, and rotate the secrets the server could read — model provider API keys, database credentials, cloud keys stored in flows or environment variables.

No official indicators of compromise have been published. Previdian lists attacker IP addresses only for paying customers.

The expert view

Root cause. This is classic OS command injection (CWE-78) in a new place. The stdio transport is, by design, "launch a local process"; Langflow treated the command line as user data and passed it to a shell wrapper. The env field compounded it: environment variables such as LD_PRELOAD or PATH can change what a spawned process loads, so even a restricted command list would not have been enough on its own.

Two advisories, one sink. There are two related records. GHSA-7w94-79vh-5mr2, published September 10, 2026 and later assigned CVE-2026-105740, lists 1.9.0 as the fix. GHSA-w794-rj3p-xv45, published September 28 (tracked by The Hacker News as CVE-2026-105697), explains why that was not the end: 1.9.0 checked input at the API, but other routes — including building a flow with the MCP Tools component — still reached the unvalidated execution point. Version 1.10.3 enforces the policy right before the process is spawned and drops the shell wrapper. That is the right fix: validate at the sink, not at one of several doors leading to it. Anyone who patched to 1.9.0 in September and moved on should look again.

Severity in context. Both advisories score 9.9 (CVSS 3.1, vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). "Privileges required: low" is accurate on a locked-down instance. On a default pip install with auto-login, it is effectively unauthenticated, so the score, if anything, understates the risk for exposed hobby and proof-of-concept deployments — exactly the kind that tend to sit on cloud VMs holding real API keys.

How solid is the exploitation evidence? Moderately. Previdian's page reports 1,512 attempts from 27 IP addresses in 15 countries, first seen September 19 and peaking around October 11; The Hacker News reported 1,423 at the time of its October 15 article. All of it comes from a single sensor, the payloads are not public, and the flaw is not in CISA's Known Exploited Vulnerabilities catalog as of this writing. Attempts against a honeypot show attackers are scanning and trying; they do not tell us how many real instances were compromised. That number is unknown.

The broader pattern. MCP turns "configure a tool" into "run a program", and several AI platforms have learned this the hard way this year. Low-code AI builders are particularly exposed: they are designed so non-specialists can add integrations, they hold many credentials in one place, and they are often stood up quickly outside normal change control. Treat any setting that names a command, a module path or a URL to load as code execution, and gate it accordingly.

Still unknown: how many internet-exposed Langflow instances remain below 1.10.3, whether any confirmed victims exist, and whether attackers are targeting the incomplete 1.9.0 fix specifically.

Official sources

• Langflow GitHub Security Advisory GHSA-w794-rj3p-xv45 — OS command injection via MCP stdio configuration, fixed in 1.10.3
• Langflow GitHub Security Advisory GHSA-7w94-79vh-5mr2 — authenticated RCE via MCP stdio transport (CVE-2026-105740)
• Langflow documentation — API keys and authentication (auto-login settings)
• Previdian — CVE-2026-105740 sensor telemetry
• Coverage: The Hacker News — Langflow's critical authenticated RCE flaw targeted in 1,423 honeypot exploit attempts (October 15, 2026)