TL;DR

On 2026-09-08 IBM's product security team published a single bulletin covering eleven CVEs in Langflow OSS 1.0.0 through 1.11.5, all leading to arbitrary code or OS-command execution on the Langflow host, all fixed in Langflow 1.11.6, with no workaround. Three need no authentication at all (CVSS 9.8): CVE-2026-79724 (OS command injection), CVE-2026-85025 (code execution and chat-session tampering through publicly shared MCP project endpoints), and CVE-2026-81204 (code injection during graph construction). The other eight (CVSS 8.8) give any authenticated non-admin user code execution through incomplete security-scanner blocklists, unguarded eval(), flow display names, custom components in stored flows, MCP stdio command arguments, and MCP Tools components. The press covered one CVE of the eleven; the Langflow project's own advisory index carries none of them under these ids. This is a separate batch from CVE-2026-0768, which is being mass-exploited — if you patched for that one, check this version number too.

What happened

IBM (Langflow's corporate parent since the DataStax acquisition) is now the CNA for Langflow CVEs, and disclosed this batch as IBM Security Bulletin 7286666, titled "Langflow is vulnerable to arbitrary code execution due to multiple incomplete code security controls and missing execution guards." The bulletin was published and last modified on 2026-09-08 and lists the affected range as Langflow OSS 1.0.0 through 1.11.5 on Windows, Linux and macOS, remediation upgrade to 1.11.6 or later, and "None identified" under workarounds. The eleven CVEs, with IBM's own scores and weakness classes:

CVE CVSS 3.1 Auth needed Root cause (IBM's description)
CVE-2026-79724 9.8 No OS command injection — improper neutralization of special elements in an OS command (CWE-78)
CVE-2026-85025 9.8 No Arbitrary code execution and chat-session access/modification through publicly shared MCP project endpoints — inadequate public-flow security enforcement and session isolation (CWE-863)
CVE-2026-81204 9.8 No Code injection during graph construction (CWE-94)
CVE-2026-81941 8.8 Yes (non-admin) OS command execution by constructing flows with MCP Tools components, bypassing admin-only controls (CWE-284)
CVE-2026-81211 8.8 Yes Python execution via improper authorization of custom components in stored flows (CWE-862)
CVE-2026-81940 8.8 Yes Code injection via flow display names (CWE-94)
CVE-2026-78569 8.8 Yes Code execution due to incomplete security-scanner blocklists (CWE-78)
CVE-2026-78575 8.8 Yes Command execution via improper validation of MCP stdio command-line arguments (CWE-78)
CVE-2026-76059 8.8 Yes Security-scanner bypass using annotated class-body assignments → OS command execution (CWE-693)
CVE-2026-79742 8.8 Yes Code execution due to incomplete environment-variable blocklists (CWE-94)
CVE-2026-78571 8.8 Yes Code execution through unguarded eval() calls on attacker-controlled input (CWE-94)

Read the right-hand column as a list: incomplete blocklist, incomplete blocklist, scanner bypass, unguarded eval, unguarded eval. Langflow's security model for the code its users and flows supply is a denylist-and-scanner layer in front of Python execution, and this bulletin is eleven independent findings that the layer has holes. That is the same structural diagnosis every prior Langflow entry in this repo reached, from CVE-2026-33017 through CVE-2026-0768 — and it is why the practical advice at the bottom is about exposure, not just version numbers.

What the secondary records add. NVD published CVE-2026-81204 on 2026-09-10 with IBM's 9.8 score (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, CWE-94) and the IBM bulletin as its only reference; the GitHub Advisory Database mirrored it as GHSA-82x2-gm4f-9fwx on 2026-09-11, unreviewed, with no patched version filled in — so pip audit-style tooling keyed on GHSA data may not yet flag 1.11.5 as vulnerable. Forkast's 2026-09-11 roundup describes the CVE-2026-81204 mechanism as the lfx code parser handing a component's return-type annotation source to eval() unsanitized, and the blocklist gaps as omitting process-spawning primitives; that detail is Forkast's, not IBM's, and is repeated here with that attribution.

A version discrepancy worth knowing about. The Langflow repository's own security-advisory index published GHSA-7w94-79vh-5mr2 on 2026-09-10 — "Authenticated RCE via MCP Stdio transport allows any user to execute arbitrary OS commands on the server" (CVSS 9.9, credit AbdrrahimDahmani): a user-supplied MCP server command is embedded in bash -c "exec {command}" with no validation and re-executes every time the server list loads, and the endpoint also accepts LD_PRELOAD/PATH environment injection. That advisory lists affected 1.8.3, patched 1.9.0 and carries no CVE. IBM's CVE-2026-78575 describes the same component (MCP stdio command-line arguments) but says 1.0.0–1.11.5, fixed 1.11.6. Either these are two different bugs in the same code path, or the 1.9.0 fix was incomplete and 1.11.6 is the real one — the two pages do not say which, and this sweep did not resolve it. Prefer the IBM range: it is the CNA's record, it is the later of the two, and a reader on 1.9.0–1.11.5 who trusted the GHSA page would believe they were safe.

Where the fix landed. The Langflow GitHub releases page lists v1.11.6 with two notes — "backport security and correctness fixes to 1.11.6" and an MCP change to "preserve public variables and expose stdio headers" — and no CVE ids; 1.12.0 and 1.12.1 also exist above it. Nothing in the release notes maps a commit to a CVE, so the bulletin is the only place the eleven ids are enumerated.

Am I affected?

Vulnerable if you run any Langflow from 1.0.0 to 1.11.5 — and for the three unauthenticated CVEs, if the API is reachable by anyone you don't trust. Public MCP projects (CVE-2026-85025) are the one to check first: a flow you deliberately shared as a public MCP endpoint is, on an unpatched instance, a code-execution endpoint.

pip show langflow 2>/dev/null | grep -i '^version'         # < 1.11.6 → vulnerable
docker ps --format '{{.Image}}' | grep -i langflow           # check the tag, not the running app's banner
# Reachable off-box?
ss -tlnp | grep -E ':7860|langflow'
# Public MCP projects / public flows are the unauthenticated surface for CVE-2026-85025:
# in the UI: Projects → MCP Server tab → any project set to public.
# Any flow that uses an MCP stdio server, MCP Tools component, or custom component
# is an authenticated-user → host-RCE path on < 1.11.6.

If the instance was internet-reachable on 1.0.0–1.11.5 with a public MCP project or with auto_login on, assume the environment was readable: this is the same class of host, and the same key ring, that the CVE-2026-0768 campaign has been draining since 2026-08-30. No exploitation of these eleven ids has been reported as of 2026-09-13; Langflow's disclosure-to-exploitation history (20 hours for CVE-2026-33017) argues against waiting for one.

If you are affected

  1. Upgrade to 1.11.6 or later (IBM's stated fix; there is no workaround). Then put authentication in front of the API and take public MCP projects private until you have confirmed the version — the Unit 42 agentic-scanning case is the documented instance of an autonomous attacker's Langflow exploit failing only because auth was on.
  2. Rotate what the process could read — playbooks/rotating-cloud-credentials.md: OpenAI/Anthropic/AWS keys in the environment, the Langflow superuser password and secret key, database credentials, and any SSH key on the host.
  3. If there is any sign of prior access, treat the host as compromised: playbooks/if-your-webapp-was-compromised.md.

Prevention

  • prevention/agent-sandboxing.md — a product whose feature is "run user-supplied Python and shell commands" needs an isolation boundary below its blocklist, not a longer blocklist. Eleven scanner-bypass CVEs in one bulletin is the empirical case.
  • prevention/mcp-hygiene.md — three of the eleven are MCP-shaped (public MCP project endpoints, MCP stdio command arguments, MCP Tools components). An MCP server definition is a command line; treat the ability to add one as the ability to run code.
  • prevention/credential-hygiene.md — the Langflow host's environment is where the expensive keys live; scope them and keep them out of .bash_history.
  • Watch the CNA, not just the project. For Langflow, security bulletins now come from IBM PSIRT, not from the langflow-ai/langflow advisory tab, and one bulletin can carry a dozen ids the press will never enumerate. Subscribe to ibm.com/support/pages bulletins for Langflow and to the NVD feed for ibm:langflow_oss.

Update — 2026-09-15: a twelfth IBM-assigned CVE against the same range (CVE-2026-12763, moderate)

CVE-2026-12763 (CVSS 4.2, GHSA-vhrg-69rg-gwv4; NVD and the advisory database 2026-09-14; IBM bulletin 7286662) — "IBM Langflow OSS 1.0.0 through 1.11.5 could allow an authenticated attacker to access another user's MCP server context due to improper cache key isolation in the MCP Tools component." Same affected range as the eleven above; the database copy lists no patched version and this sweep did not fetch the bulletin, so treat 1.11.6 as covering it only once IBM's page says so. Not a code-execution bug — a cross-user data leak in the same MCP Tools component that carries two of the 8.8s — but it is a twelfth id against 1.0.0–1.11.5 that the project's own advisory tab does not list.

Update — 2026-09-30: two vendor advisories published 2026-09-28 (an SSRF guard that shipped disabled and warn-only, fixed 1.10.3; deprecated build endpoints that executed other users' flows, fixed 1.10.1) and a VulnCheck CVE for an eval() sink in component options (CVE-2026-101861, fixed 1.12.0)

Langflow's own tab gained two entries on 2026-09-28, neither with a CVE at fetch time:

  • GHSA-j8f7-x8jm-wmm4 — SSRF in URL-taking components (Moderate, 6.3). Before 1.10.3 (langflow-base 0.10.3, lfx 1.10.3, lfx-docling 0.1.2), the SSRF protection for components that fetch URLs "shipped disabled by default with warn-only enforcement," and several components — RSS, SearXNG, Web Search, Home Assistant, Glean, Docling — had none at all, so an authenticated flow builder could make the server reach loopback, RFC 1918, link-local and cloud-metadata addresses. Do not set LANGFLOW_SSRF_PROTECTION_ENABLED to false after upgrading; allowlist internal hosts with LANGFLOW_SSRF_ALLOWED_HOSTS if a flow legitimately needs them. Credits andifilhohub (analysis), erichare (remediation).
  • GHSA-gh98-4phw-6fmw — cross-user flow access and vertex execution via deprecated /api/v1/build/{flow_id}/vertices endpoints (Moderate, 5.4). Two deprecated, undocumented but still-registered routes lacked ownership checks, so any authenticated user who knew a flow_id could enumerate vertex IDs and execute individual vertices of another user's private flow, with audit records written under the victim. Affected ≥ 1.0.0 < 1.10.1 (langflow-base < 0.10.1); fixed 1.10.1; block both POST paths at a reverse proxy until then — the UI does not use them. Credits dhirajranka, andifilhohub.

And on 2026-09-28 VulnCheck published CVE-2026-101861 (CVSS 4.0 2.1) for an unsafe eval() in schema.py: an authenticated attacker who places a Python object with a malicious repr into a component's input options list gets code execution when the component is converted into a LangChain tool via ComponentToolkit.get_tools() — including during custom-component saves through the API — because the options are interpolated into a Literal type string that is passed to eval(). Affected 1.0.16 and 0.0.94 before 1.12.0; the vendor advisory is GHSA-33p4-w7j3-33mw. The score is low (authenticated, high complexity); the pattern — options text reaching eval() — is the same sink class as CVE-2026-0770 and CVE-2026-0768 in this corpus. Upgrade target for all three: ≥ 1.12.0.

Update — 2026-10-06: GitHub (as CNA) assigned five CVE ids on 2026-10-05 to Langflow vendor advisories this file and its siblings already carry — the MCP stdio RCE is CVE-2026-105740 (9.9, < 1.9.0) and a second 9.9, CVE-2026-105697, covers the stdio transport's bash -c wrapping through 1.10.2; the deprecated build endpoints are CVE-2026-105698 (5.4); an MCP resources/read URI that was authenticated but not authorized is CVE-2026-105699 (7.1, 1.6.8 – 1.9.0); and an IP-spoofing bug on the MCP project install endpoint is CVE-2026-105741 (7.1, 1.5.0 – 1.10.2); four older advisories not previously tracked here get their own file

The NVD keyword query for Langflow (published 2026-09-28 → 10-06) returns five security-advisories@github.com records dated 2026-10-05, all "Awaiting Analysis"; the mapping below uses only the GHSA ids each CVE record itself references:

  • CVE-2026-105740 — 9.9. "Prior to 1.9.0, any authenticated Langflow user can achieve Remote Code Execution (RCE) on the server by adding an MCP server with the 'Stdio' transport." References GHSA-7w94-79vh-5mr2 (the stdio RCE in this file's table) and a second vendor id, GHSA-w794-rj3p-xv45 (not opened), plus PR #12290.
  • CVE-2026-105697 — 9.9. "Before Langflow 1.10.3, the MCP stdio transport launched whatever command / args a user put in an MCP server configuration, with no allowlist and (before 1.10.3) wrapped in bash -c"; references PRs #12290 and #14036 and no GHSA. Read with the row above: 1.9.0 removed the direct RCE, 1.10.3 removed the shell wrapper and added an allowlist — which is why the upgrade target in this file has been ≥ 1.12.0, not 1.9.x.
  • CVE-2026-105698 — 5.4. "From 1.0.0 until 1.10.1, Langflow did not verify flow ownership in the deprecated POST /api/v1/build/{flow_id}/vertices … handlers." References GHSA-gh98-4phw-6fmw (the 09-30 update above).
  • CVE-2026-105699 — 7.1 (CVSS 4.0). "From 1.6.8 until 1.9.1, Langflow authenticated access to the project identifier in a project-scoped MCP connection but did not authorize the resource URI supplied to resources/read"; references PR #12818 and the v1.9.1 release, no GHSA — so it is not paired here with the cross-project MCP resource-handler advisory the MCP batch tracks, although the description matches.
  • CVE-2026-105741 — 7.1. "From 1.5.0 until 1.10.3, an IP spoofing vulnerability in the Model Context Protocol (MCP) configuration installation endpoint (POST /api/v1/mcp/project/{project_id}/install)"; references PR #13915, release v1.10.3, no GHSA.

Separately, the same database sweep surfaced four Langflow advisories this repo had never tracked — the Fernet key derived from random.seed() (CVE-2026-9205), the webhook authentication bypass (CVE-2026-8505), the unsandboxed PythonREPLComponent (CVE-2026-10561) and the Smart Transform prompt-injection-to-eval() (CVE-2026-7700) — each with IBM-versus-vendor version and score disagreements; they are written up in 2026-10-langflow-fernet-key-webhook-bypass-python-repl-cve-wave. Upgrade target across all of it: 1.12.4 (PyPI latest, 2026-10-06).

Update 2026-10-15: CVE-2026-105740 is being exploited against exposed instances

Previdian, a vulnerability-intelligence vendor that runs honeypot sensors, reports exploitation attempts against the MCP stdio RCE (CVE-2026-105740, authenticated, 9.9, fixed 1.9.0): first seen 2026-09-19, 1,553 attempts from 27 source addresses in 15 countries as of the page read on 2026-10-15, with a peak of about 333 attempts on 2026-10-11. The Hacker News carried the figure as 1,423 attempts on the morning of 2026-10-15; the vendor page is a live counter, so the number moves. Per the outlet's account of the sensor data, attackers log in with common credentials, use the bearer token against the MCP server configuration endpoint, and because the stored configuration re-executes whenever the server list loads it persists as a backdoor that normal flow review does not show; observed probes read environment variables and configuration values, reached for the host filesystem through Docker, read system account files and ran execution checks, and the same sources also brute-forced logins and exploited other Flowise and Langflow CVEs. The Previdian page itself reports only volume, sources and timing and does not describe post-exploitation. The CVE is not in CISA's KEV catalogue as of the 2026-10-15 feed. Status moves to active: the fix has existed since 1.9.0, but a Langflow reachable from the internet with a guessable account is being attacked now. Set LANGFLOW_AUTO_LOGIN=false, enforce unique passwords, restrict accounts, review authentication logs and requests to the MCP server endpoints, and audit stored MCP server configurations for stdio commands nobody added.

Sources

2026-09-15 update source: - GitHub Advisory Database — GHSA-vhrg-69rg-gwv4 (CVE-2026-12763) — fetched 2026-09-15; CVSS 4.2, 1.0.0 – 1.11.5, no patched version listed, IBM bulletin 7286662 referenced. - NVD API — keywordSearch=Langflow, published 2026-09-28 → 10-06 — fetched 2026-10-06: CVE-2026-105697, -105698, -105699, -105740, -105741 (all 2026-10-05, CNA GitHub, scores and descriptions as quoted, references as listed); also CVE-2026-101861 and the two MITRE ids tracked in the Ro1ME file.