Langflow before 1.9.0 lets any logged-in user run shell commands on the server by adding an MCP server with the Stdio transport. The flaw is CVE-2026-105740, scored 9.9 (Critical), and the fix is Langflow 1.9.0. A news report says honeypots logged 1,423 exploit attempts; that number comes from one vendor's sensors and we have not seen the raw data. This post separates the two, and notes that version 1.9.0 closes only part of the problem.
| Question | Short answer |
|---|---|
| Am I affected? | If you run Langflow older than 1.9.0 and anyone with an account is not fully trusted |
| Is there a fix? | Yes: 1.9.0 (langflow-base 0.9.0) blocks the API path; 1.10.3 fully fixes the related execution path |
| Needs a login? | Yes, but any role, per the CVE record |
| Exploited in the wild? | Reported by Previdian from honeypot sensors; we have not seen the raw data |
| Does data leave my machine? | An attacker with a shell can read anything the Langflow process can, including API keys |
What is verified: the mechanism
Per the OpenCVE record (published October 5, 2026) and Mend's database entry:
- An authenticated user adds an MCP server and chooses the Stdio transport. Stdio servers are launched as local processes, so the config holds a command.
- Langflow passes that command to a bash shell with no validation, allowlisting or sandboxing.
- The command runs when the server list is fetched, so merely opening the list triggers it. The saved config persists.
- The
envfield also accepts arbitrary variables such asLD_PRELOADorPATHoverrides.
The weakness is CWE-78. Both records cite the fix commit, pull request #12290 and the GitHub advisories GHSA-w794-rj3p-xv45 and GHSA-7w94-79vh-5mr2. Mend lists affected ranges of langflow 1.8.3 to below 1.9.0 and langflow-base 0.5.0 to below 0.9.0.
Two details in the CVE record explain why this bug is easy to miss. First, the command is not run at the moment you save it. OpenCVE's analysis of the record says it executes "when the server list is fetched", so a harmless-looking GET that populates the settings page is enough. Second, the OpenCVE entry marks the exploitation status as proof of concept ("poc") and the impact as total, while listing the CVSS v3.1 vector as network-reachable, low complexity, low privileges, no user interaction, with a changed scope. "Changed scope" means the damage reaches beyond the Langflow application to the host it runs on.
The Hacker News describes the sequence an attacker follows, quoting Langflow's own advisory: log in as a regular non-admin user, send a crafted POST to /api/v2/mcp/servers/{server_name} with a command field holding the payload, then trigger it with a GET to /api/v2/mcp/servers?action_count=true. Because the entry is stored, it re-runs each time the list is loaded. The same report quotes Langflow as saying that, unlike custom component code, which is visible in the flow editor, "MCP server configs are stored in project settings and are not visible during normal flow review." That is why a reviewer reading a flow may never see the planted command.
This is a general MCP hazard, not only a Langflow one: a stdio MCP entry is a command. See MCP server security review and the MCP practical guide.
What is claimed: the honeypot count
The Hacker News, in a story dated October 15, 2026, reports that Previdian recorded 1,423 exploitation attempts against its honeypot sensors since September 19, 2026, from 27 unique IP addresses in 15 countries. By the report's account the activity ramped up on October 11 with 333 attempts, and 66 had been seen on October 15 at time of writing. The article carries a later update that raises the total to 1,706 attempts from 28 IP addresses, with 316 on October 15.
Our first draft of this post said we could not load that page. It now loads, so the numbers above are what the article says. What remains unverified on our side is the underlying data: we have not seen Previdian's own alert or logs, and we cannot independently check the counts. A honeypot count also describes one vendor's sensors. It shows that people are scanning for and testing the bug; it does not show how many real instances were compromised, and OpenCVE's record still lists the CVE as not in the CISA Known Exploited Vulnerabilities catalogue as of its October 5 analysis.
What the honeypot reportedly saw
The article gives more detail than the headline. Previdian's founder Ryan Dewhurst told The Hacker News that attackers first checked the Langflow version, then tried /api/v1/auto_login, which returned 403 on the honeypot because it was disabled. They then logged in with a common username and password and used the bearer token straight away on the MCP configuration endpoint. In other words, the reported route to "authenticated" was a weak password, not a second bug.
Captured payloads, as reported, included attempts to read environment variables and Langflow settings (the article names LANGFLOW_SECRET_KEY and LANGFLOW_SUPERUSER_PASSWORD) and send them to an external address, Docker commands aimed at the host filesystem and /etc/passwd, and simple probes such as id and whoami. One source address was also linked, by GreyNoise and Previdian data cited in the article, to attacks on other Langflow and Flowise CVEs, which the article reads as a single unidentified actor working through exposed instances. Their goals are described as unclear.
If this report is accurate, the targets of the payloads tell you what to rotate: the secret key that signs Langflow sessions, the superuser password, and any model or cloud keys in the process environment.
Why "authenticated" is not much comfort
A critical score with a login requirement still matters when accounts are easy to get. Two routes are on record. The GitHub advisory for the related CVE-2026-105697 says that with the default LANGFLOW_AUTO_LOGIN=true, a GET to /api/v1/auto_login hands out a token without credentials, so an exposed default instance needs no account at all. The advisory also says auto-login is documented as a development-only setting, and that with it disabled any authenticated non-admin user can still exploit the flaw. The second route is the one Previdian describes: guessing a common password.
How this relates to CVE-2026-105697 and the 1.10.3 fix
The GitHub advisory GHSA-w794-rj3p-xv45 for CVE-2026-105697 (CVSS 9.9, published September 28, 2026) describes the same root cause: the stdio transport launched whatever command and args a user put in an MCP server config, wrapped in bash -c "exec {command_str} ...". The OpenCVE record for CVE-2026-105740 cites that same advisory identifier next to its own. Our first draft treated the two as separate records with different fixes. Reading the advisory, they describe one weakness fixed in two steps:
| Release | What the advisory says |
|---|---|
| 1.1.2 to 1.4.x | The MCP Stdio component ran the command field with no validation |
| 1.5.0 to 1.8.x | The "Add MCP Server" page and /api/v2/mcp/servers API were added; stored stdio configs launched via bash -c with no validation |
| 1.9.0 to 1.10.2 | Pull request #12290 added an allowlist and argument and environment checks to the REST model. The execution sink still used bash -c with no validation, so configs outside that model, such as an MCP Tools component value embedded in a flow or passed as a tweak, could still run commands |
| 1.10.3 and later | Pull request #14036 enforces one policy at the API, at flow execution and just before the process is spawned, and removes the shell |
The advisory lists the fixed package versions as langflow 1.10.3, langflow-base 0.10.3 and lfx 1.10.3. It also notes that the command runs before any MCP handshake, which is why it executes even when the interface reports that the stdio server failed to start.
What the allowlist permits is worth knowing. Per the advisory and the text of pull request #12290, the permitted commands are node, python, python3, npx, uvx and docker, with cmd, sh and bash allowed only to wrap one of those. Arguments are checked for shell metacharacters, and environment variables such as LD_PRELOAD, NODE_OPTIONS, PYTHONPATH and BASH_ENV are blocked. On 1.10.3 the advisory's example request using touch is rejected with a message that the command is not allowed.
Not only Langflow
The weakness is a family, not one product. OX Security's April 2026 advisory lists command injection through MCP stdio configuration in several tools, including Langflow, LiteLLM, GPT Researcher, Agent Zero and LangBot, all rated critical there. Each takes a user-supplied command and args pair and hands it to the MCP SDK's stdio parameters. The pattern also appeared on the developer side: see Cursor MCP config poisoning RCE. The lesson is the same everywhere: an MCP stdio entry is a program invocation, and whoever can write it can run code.
Update (October 20, 2026): 1.9.0 is not the end of the fix
Reading the primary advisory for the related CVE, the practical target version is 1.10.3 or later, not 1.9.0. The advisory also says 1.11.0 adds optional stricter modes for multi-tenant deployments, and that on 1.10.3 and later the allowlist still lets npx and uvx run any package by default. For shared deployments it recommends setting LANGFLOW_MCP_SERVER_ALLOWED_PACKAGES to the exact packages those launchers may run, and enabling LANGFLOW_MCP_SERVER_INTERPRETER_HARDENING=true and LANGFLOW_MCP_SERVER_DOCKER_HARDENING=true. On 1.11.1 and later it adds that restricting custom code, for example with LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false, also limits MCP stdio servers to superusers. The Hacker News update puts reported attempts at 1,706 from 28 addresses.
What this means if you run Langflow or similar tools
- Upgrade to 1.10.3 or later and confirm with
pip show langflow. Version 1.9.0 alone leaves the flow-embedded path open, per the advisory. - Audit MCP server entries. Look for stdio servers you did not add, especially commands with shells,
curl,LD_PRELOADor unusualPATHvalues. - Limit accounts and exposure. Set
LANGFLOW_AUTO_LOGIN=false, replace default or common passwords, give accounts only to trusted users and keep the UI off the public internet. Both the advisory and Previdian make these the first steps. - Review requests. Previdian recommends reviewing authentication logs and requests to
/api/v2/mcp/servers/for suspicious activity. - Rotate secrets the Langflow process can read if you ran an exposed, unpatched instance: model API keys and cloud credentials.
- Look at process trees for shells spawned by the Langflow process, and for outbound connections from it to addresses you do not recognise.
- Check saved configs, not only flows. Because stored MCP server configs live in project settings and not in the flow editor, list them directly and remove any you cannot account for.
What Beam can and cannot do here
Langflow is a server, not a local coding agent, so Beam's hooks do not sit in front of it. Beam's scan of MCP configs on your own machine applies the same lesson to .mcp.json-style files: it flags risky command patterns and a missing version pin heuristically. See how Beam works. It does not patch or monitor remote servers.
If you run Langflow or another Python service yourself, beam cve check . reads pip, poetry, uv and Pipfile lockfiles and matches the pinned versions against AgentBeam's CVE database, failing a CI run with exit code 2 when a finding meets --fail-on. beam monitor can also watch the service's logs for attack patterns such as command injection, as a watch-only, heuristic layer. See app monitoring and the CVE database.
Frequently asked questions
What is CVE-2026-105740?
It is a CWE-78 OS command injection in Langflow before 1.9.0. Any authenticated user can add an MCP server with the Stdio transport, and its command is passed to bash -c without validation and runs when the server list is fetched.
How severe is it?
CVSS v3.1 scores it 9.9 (Critical), and Mend also lists a CVSS v4 score of 9.4. It needs a valid login of any role but no user interaction.
Is 1.9.0 enough to be safe?
Not fully. Per the GitHub advisory for the related CVE-2026-105697, 1.9.0 added an allowlist at the API, but the execution path still used bash -c until 1.10.3, so configs embedded in flows could still run. Upgrade to 1.10.3 or later.
Is the 1,423 honeypot number verified?
It is a reported figure. The Hacker News attributes it to Previdian honeypot sensors, counted since September 19, 2026, from 27 IP addresses, and later updated it to 1,706 attempts from 28 IPs. We have not seen the raw honeypot data.
Is this the same as the earlier unauthenticated Langflow bugs?
No. This one requires a logged-in account. But the GitHub advisory for the related CVE-2026-105697 notes that the default LANGFLOW_AUTO_LOGIN=true setting hands out a token without credentials, and Previdian saw attackers log in with a common username and password.
What should I do if I run Langflow?
Upgrade to 1.10.3 or later, set LANGFLOW_AUTO_LOGIN=false, use strong unique passwords, keep the instance off the public internet, and review /api/v2/mcp/servers requests and the MCP server list for entries you did not add.
Related reading
- MCP server security review
- MCP security: a practical guide
- MCP TypeScript SDK OAuth credential leak
- Cursor MCP config poisoning RCE
- AI agent security incidents timeline
- AI agent web and transport security
Details are accurate as of October 20, 2026, from the CVE records, the GitHub advisory and The Hacker News report. We have not seen Previdian's raw data. Check the Langflow advisories for later changes.