Langflow: PythonREPLComponent executes unsandboxed Python code, enabling authenticated RCE and privilege escalation

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:

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.