On October 5, 2026, a CVSS 9.9 critical vulnerability was disclosed in Langflow, the open-source platform many builders use to prototype AI agents and workflows: CVE-2026-105697, an OS command injection (CWE-78) in its MCP server handling. Before Langflow 1.10.3, the MCP stdio transport would launch whatever command a user typed into the MCP server configuration — no allowlist, wrapped in bash -c. A public proof-of-concept is already available. If you self-host Langflow, upgrade to 1.10.3 (or langflow-base 0.10.3 / lfx 1.10.3) now — and disable the dev-only auto-login setting if it's still on. This post explains exactly what broke, whether you're exposed, and how to patch.
What CVE-2026-105697 is
Langflow lets users connect MCP (Model Context Protocol) servers to flows — either through the UI (Settings → MCP Servers → Add MCP Server, which hits POST/PATCH /api/v2/mcp/servers/{server_name}) or through the MCP Tools component inside a flow. With a stdio transport, "connecting" to an MCP server means the platform launches a local process.
The problem: before version 1.10.3, Langflow took the command and args fields from the MCP server configuration and executed them directly — with no allowlist of permitted commands, and wrapped in bash -c "exec {command} ...". So a "server" whose command was touch /tmp/pwned, rm -rf /something, or a reverse shell wasn't validated or rejected — it ran on the Langflow host as the Langflow process user the moment Langflow tried to connect to the server (listing servers, loading tools, or running the flow). Even if the UI later reported that the stdio server failed to start, the command had already executed.
The worst part: unauthenticated on default instances
Most critical RCEs at least require an account. This one often doesn't.
Langflow ships with LANGFLOW_AUTO_LOGIN=true by default — documented as a development-only setting. With it enabled, a single request to GET /api/v1/auto_login hands out a token without credentials. So on any Langflow instance exposed to the internet with the default configuration, this vulnerability was reachable without an account at all.
With auto-login disabled (as it should be in production), the flaw is still exploitable by any authenticated non-admin user — anyone who can reach the MCP server settings or build a flow with the MCP Tools component. In shared or team environments, that's a wide privilege boundary: a low-privilege user gets OS-level command execution on the host.
Which versions are affected
| Package | Vulnerable | Patch to |
|---|---|---|
| Langflow | < 1.10.3 | 1.10.3 |
| langflow-base | < 0.10.3 | 0.10.3 |
| lfx | < 1.10.3 | 1.10.3 |
Disclosed October 5, 2026 (record modified October 6). Per the CVE metadata: public PoC available, not yet in the CISA Known Exploited Vulnerabilities catalog (no confirmed in-the-wild exploitation as of publication), EPSS 0.40% — but with a PoC public and a 9.9 score, treat the window between disclosure and patching as your real risk.
Warning: check
LANGFLOW_AUTO_LOGINfirst, not your version number. If your instance is internet-exposed and auto-login was on, assume it was reachable unauthenticated and review your logs and host for signs of compromise before you trust the patch alone.
Are you exposed? A 60-second check
-
Is your Langflow reachable from the internet? Check your reverse proxy, security groups, or
curlit from outside your network. -
Is
LANGFLOW_AUTO_LOGIN=true? Check your environment or Docker compose. If yes, this setting should never have been on outside local dev. -
Which version are you on?
pip show langflowor check the Docker image tag. Anything below 1.10.3 / 0.10.3 is vulnerable. - Who has accounts? With auto-login off, every non-admin account was a potential entry point — review your user list.
How to patch
Prerequisites: back up your Langflow data (flows, credentials, the database or ~/.langflow directory) before upgrading.
Step 1 — Upgrade to the fixed version
If you installed via pip:
pip install --upgrade "langflow>=1.10.3"
If you're using the langflow-base package:
pip install --upgrade "langflow-base>=0.10.3"
If you run the official Docker image:
docker pull langflowai/langflow:latest
# then recreate your container (your data volume holds flows + db)
Step 2 — Turn off auto-login in anything that isn't local dev
export LANGFLOW_AUTO_LOGIN=false
or in your Docker compose / env file:
LANGFLOW_AUTO_LOGIN=false
Step 3 — Don't expose Langflow directly
Put Langflow behind a reverse proxy with authentication (or a VPN / private network), and restrict which hosts can reach it. Langflow holds API keys and credentials in its flows — it should never be a public URL with default settings.
Step 4 — Look for compromise if you were exposed
If your instance was internet-reachable with auto-login on and running a vulnerable version: review flow and MCP server configurations for entries you didn't create, check the host for unexpected processes or files, rotate every credential and API key stored in Langflow, and consider rebuilding the host from a clean image.
The bigger lesson: MCP server configs are privileged
This is the part every agent builder should internalize, even if you've never touched Langflow. An MCP stdio server definition is arbitrary code execution by design — it launches a process on the host. That means the configuration surface for MCP servers should be treated with the same seriousness as SSH access or sudo: allowlists for commands, least-privilege users, and no unauthenticated access, ever.
The same caution applies to the MCP nodes in your own stack. If you're wiring MCP into n8n, our MCP + n8n troubleshooting guide covers the transport pitfalls — and the general principle stands: anything that launches a process on your behalf must never accept unvalidated input from a lower-privilege user. This is also the second high-severity AI-infrastructure CVE in a week affecting agent builders, after GitLab's AI Gateway sandbox escape — the attack surface is moving from models to the glue around them.
FAQ
What is CVE-2026-105697?
A critical (CVSS 9.9) OS command injection in Langflow, disclosed October 5, 2026. Before Langflow 1.10.3, the MCP stdio transport executed whatever command a user put in an MCP server configuration — no allowlist, wrapped in bash -c — running it on the Langflow host. Fixed in Langflow 1.10.3, langflow-base 0.10.3, and lfx 1.10.3.
Do I need an account to exploit it?
On instances with the default LANGFLOW_AUTO_LOGIN=true exposed to the internet: no — GET /api/v1/auto_login issues a token without credentials. With auto-login disabled, any authenticated non-admin user could exploit it.
Is there a public exploit?
Yes — proof-of-concept references and code are publicly available. It is not in the CISA KEV catalog yet, meaning no confirmed in-the-wild exploitation has been recorded. Patch anyway; the PoC closes the gap between theory and practice.
I'm an n8n user — should I care?
Yes, for the pattern, not the package. n8n has its own MCP integrations, and the same class of bug — unvalidated command/argument handling in a tool-execution path — keeps appearing across agent infrastructure (see n8n's own October CVEs). Audit any workflow platform where a low-privilege user can define something that launches a process.
Conclusion
CVE-2026-105697 is a textbook reminder that the most dangerous code in an AI agent stack is often not the model — it's the launcher. A configuration field that accepts a command and runs it is a shell, and Langflow treated it like a settings form. Upgrade to Langflow 1.10.3, kill auto-login outside local dev, and stop exposing workflow platforms to the open internet. Then audit the rest of your agent glue for the same shape of flaw — because this class of bug is having a very busy October.
Images: Pexels
Originally published on CortexFlow. Free n8n templates: https://cortexflow.tech/templates/
Top comments (0)