GHSA-8qpj-27x8-pwpq Langflow: PythonREPLComponent executes unsandboxed Python code, enabling authenticated RCE and privilege escalation

• PyPI langflow: < 1.10.1 → fixed in 1.10.1

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.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.