Langflow CVE-2026-105697: MCP Server Config Becomes Remote Code Exec

On 5 October 2026, NVD published CVE-2026-105697, a critical OS command injection in Langflow, the visual builder for AI agents and flows. Before version 1.10.3, Langflow's MCP stdio transport launched whatever command a user put in an MCP server configuration, inside a bash shell, with no allowlist. The same week, two older Langflow advisories, a webhook authentication bypass and a weak encryption key, were added to GitHub's Advisory Database.

What's affected

CVE-2026-105697 (GHSA-w794-rj3p-xv45, CVSS 3.1 9.9):

• langflow from 1.1.2 up to, not including, 1.10.3. Fixed in 1.10.3.
• langflow-base from 0.1.2 up to, not including, 0.10.3. Fixed in 0.10.3.
• lfx before 1.10.3. Fixed in 1.10.3.

Commands could arrive through the MCP server settings page, the /api/v2/mcp/servers API, or an MCP Tools component inside a flow. The advisory says the reporter found several internet-facing Langflow servers that were vulnerable. The command ran when Langflow tried to connect, "even if the UI then reported that the server failed to start." With the default LANGFLOW_AUTO_LOGIN=true, the /api/v1/auto_login endpoint hands out a token without credentials, so an exposed default instance can be exploited without an account. With auto-login off, any authenticated non-admin user can do it.

The fix took three releases. 1.9.0 added an allowlist to the REST model but left the execution point unchecked, so 1.9.0 through 1.10.2 are still exploitable through configs embedded in flows or passed as tweaks. 1.10.3 applied the policy at the execution point and removed the bash wrapper.

Related advisories added on 5 October:

• CVE-2026-8505 (CVSS 9.8): webhook endpoints skipped API key checks when WEBHOOK_AUTH_ENABLE was false, which was the default from 1.7.0 through 1.9.0. Anyone who knew a flow's UUID could run it as the owner. Fixed in 1.9.1, which turned webhook authentication on by default.
• CVE-2026-9205 (CVSS 9.1): when SECRET_KEY was shorter than 32 characters, Langflow seeded Python's non-cryptographic random module with it to derive the Fernet key that protects stored credentials such as LLM provider API keys and database passwords. Fixed in 1.10.1. The default generated 43-character key was not affected by this part.

How to check if you're exposed

Check the installed version:

pip show langflow langflow-base lfx 2>/dev/null | grep -E '^(Name|Version)'

Check whether auto-login is on. If this returns 200 from outside your network, anyone can get a session:

curl -s -o /dev/null -w '%{http_code}\n' https://langflow.example.com/api/v1/auto_login

Review the environment for the settings these advisories depend on:

env | grep -E 'LANGFLOW_(AUTO_LOGIN|WEBHOOK_AUTH_ENABLE|SECRET_KEY)' | sed 's/=.*/=<set>/'

You can also run your requirements.txt through the free scan at gold.safeguard.sh/scan. It runs in the browser and the file never leaves your machine.

What to do now

1. Upgrade to Langflow 1.10.3 or later. That covers CVE-2026-105697 along with the webhook and Fernet key fixes.
2. Turn off auto-login and keep Langflow off the internet if you can't upgrade today. The advisory's workarounds are LANGFLOW_AUTO_LOGIN=false, no exposure to untrusted networks, and accounts only for trusted users.
3. Restrict which MCP packages can run. On 1.10.3 and later, set LANGFLOW_MCP_SERVER_ALLOWED_PACKAGES, because the default allowlist lets npx and uvx run any package. Also set LANGFLOW_MCP_SERVER_INTERPRETER_HARDENING=true and LANGFLOW_MCP_SERVER_DOCKER_HARDENING=true.
4. Limit who can configure MCP servers. On 1.11.1 and later, the advisory lists LANGFLOW_CUSTOM_COMPONENT_ADMIN_ONLY=true and LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true as ways to keep stdio server setup with superusers.
5. Re-enter stored credentials if your SECRET_KEY was short. The CVE-2026-9205 advisory says those deployments must re-enter previously stored credentials after upgrading. Rotate the provider API keys themselves too, since they may have been decryptable.
6. Hunt for leftovers. Review MCP server entries and flows for commands you don't recognize, and check the host for unexpected processes started by the Langflow user.

Why it matters

An MCP stdio server is, by design, a command your application runs. Any product that lets users add stdio servers is letting users choose a program to execute on the host. Langflow's first fix secured the form, not the place where the command actually ran, which is why versions 1.9.0 through 1.10.2 were still exposed.

The pattern to remember: validate at the point of execution, not at each way in. Flows, tweaks, imports and APIs are all doors to the same room.

AI workflow builders also tend to hold many provider keys in one database. A host-level compromise of a Langflow server is a credential incident, not just an outage.

Try it yourself

Take one internal Langflow instance and answer three questions: what version is it, is auto-login on, and can it be reached from outside your network? Then see how an exploitability check combines version, exposure and configuration into one answer.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GHSA-w794-rj3p-xv45: Langflow OS command injection via MCP stdio server configuration
• GHSA-cf6m-vc3m-7cgm: Langflow unauthenticated flow execution via webhook authentication bypass
• GHSA-jxw3-mjmx-3pqm: Langflow weak Fernet key via random.seed()
• NVD: CVE-2026-105697