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.

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.