# Langflow: how auto-login and code filtering exposed an execution path

> The Langflow vulnerabilities of October 2026 affect the authentication and execution of Python components. Analysis of public PoC, limits and fix.

Published: 2026-11-05  
Canonical: https://rootzero.eu/en/research/langflow-auto-login-mcp-code-execution-2026/

**IBM advisory of October 28, 2026.** [IBM identifies](https://www.ibm.com/support/pages/security-bulletin-langflow-oss-affected-multiple-vulnerabilities-2) several flaws in Langflow OSS up to branch 1.12.8, including **CVE-2026-93680**, authentication bypass, and **CVE-2026-110186**, code injection that can give a remote RCE. The case is interesting because Langflow is designed to assemble agent components and tools: custom components can turn flow configuration into Python execution on the server. Security depends on who can create the component and how strong the control is applied before importing it.

## Two barriers that should not be confused

Authentication answers: “Who submits the request?” Code control answers: “What can this request do?” A weakness in one does not automatically prove an RCE, but their combination can expose the second to an actor who should never have reached the interface. The IBM bulletin describes **CVE-2026-93680** as an authentication defect and **CVE-2026-110186** as code execution due to insufficient control of code generation. It also mentions the exposure of an RCE path by the enumeration of MCP tools. These descriptions are findings in the vendor advisory; they do not detail in the bulletin each request or each function called.

A [researcher-published PoC](https://github.com/al4n4n/CVE-2026-110186) documents a specific attack chain in the versions tested: With `LANGFLOW_AUTO_LOGIN=true`, the `auto_login` endpoint could return a superuser token to an unauthenticated caller; the researcher then submitted a Python component to the validation mechanism and then demonstrated its execution. It identifies this authentication path and the code scanner flaw as two links. The PoC test scope, **1.9.0 to 1.12.5**, is narrower than the update scope announced by IBM; we must not substitute the limits of a PoC for the versions that the publisher asks to correct.

## Why a list of banned modules fails

The scanner analyzed the component's syntax tree to refuse imports or access deemed dangerous, in particular `os`, `subprocess` and `ctypes`. The researcher shows that an apparently permitted module, `pydoc`, re-exports `os`. Submitted code can therefore access a prohibited capability **by another attribute path** without writing the import that the blacklist expects. The researcher also reports a variant by `numpy.ctypeslib`. The fault is not that an AI model "misunderstands" an instruction: it is a classic limit of static analysis by prohibited names in a language where objects and modules are composable.

The execution path described by the PoC goes through registering a component, validating it, writing it to the components directory, and then importing it as a Python module. Once the import is reached, the scanner is the last visible application barrier in this route. The PoC contains network traces and tests comparing vulnerable version and patched version; This provides stronger proof than a simple example of code that “should work”. However, we do not infer from this PoC that all deployments expose `auto_login`, nor that the MCP route mentioned by IBM works the same way. Configuration, network exposure and version remain decisive.

## How to find the fault class

An authorized audit begins by inventorying all routes to component registration and code execution, including agent functions and MCP tools. It then checks the rights requested by each route with an absent, weak and administrator session. The review should track which objects are actually accessible at runtime and compare the intended policy with the capabilities that permitted libraries re-export. The differential test on a corrected version makes it possible to verify the closure of the demonstrated channels.

The actual discovery of CVE-2026-110186 is described in the researcher's write-up; The above analysis follows this PoC, but the IBM bulletin groups several vulnerabilities together and does not attribute all of their paths to this single work. This is an additional reason to cite the PoC close to the details it establishes, without attributing all the conclusions of the bulletin to the same chain.

## Measure the impact and correct

A compromised Langflow server can expose the secrets it uses to connect models, providers, and internal systems. This is a plausible consequence of running code with service privileges, not proof that such exfiltration took place on a given installation. The [IBM advisory](https://www.ibm.com/support/pages/security-bulletin-langflow-oss-affected-multiple-vulnerabilities-2) recommends **Langflow OSS 1.13.0** for versions 1.0.0 through 1.12.8 and does not provide a general workaround. The inventory should note the version executed, the interface exposure, the auto-login configuration, the components created and the secrets accessible to the process. An update fixes known pathways; it does not replace the review of components and identifiers if a server was accessible before correction.

The technical lesson is twofold: a code policy based on banned names does not represent the truly achievable capabilities, and an automatic connection designed to simplify startup can make a surface that executes code public. Both boundaries must be tested separately and together.

**Primary sources:** [IBM bulletin](https://www.ibm.com/support/pages/security-bulletin-langflow-oss-affected-multiple-vulnerabilities-2), [PoC and researcher analysis for CVE-2026-110186](https://github.com/al4n4n/CVE-2026-110186), [Langflow 1.13.0 release notes](https://github.com/langflow-ai/langflow/releases/tag/1.13.0).