CVE-2026-10561: Unauthenticated Remote Code Execution in Langflow OSS PythonREPLComponent via Builtins Injection

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 issuperuser) 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). getglobals() built the exec globals from the globalimports 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").checkoutput([...]). This made the "only modules in Global Imports can be used" guarantee false, and it applied even with the default configuration (allowcustomcomponents=True).

2. No server-policy gate (locked-down deployments). Even a deployment hardened with allowcustomcomponents=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 issuperuser = 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 sessionscope

async def escalate(): async with sessionscope() as session: stmt = select(User).where(User.username == 'testuser') user = (await session.exec(stmt)).first() if user: user.issuperuser = 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 runpythonrepl() before any code is executed:

- Restricted builtins — getglobals() injects a curated safebuiltins() mapping, removing import, eval, exec, compile, open, input, globals/locals/vars, getattr/setattr, etc. (#13397) - AST validation — validatecodesafety() 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 — ensurecodeexecutionenabled() refuses to run when allowcustomcomponents=False or blockcodeinterpretercomponents=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 LANGFLOWSANDBOXBACKEND 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 LANGFLOWALLOWCUSTOMCOMPONENTS=false (or LANGFLOWBLOCKCODEINTERPRETERCOMPONENTS=true) to disable the interpreter entirely. - For deployments that must run untrusted code, configure LANGFLOWSANDBOXBACKEND for microVM isolation. - Run the Langflow service as an unprivileged user with least-privilege database credentials.