| Package | Affected versions | Patched versions |
|---|---|---|
| langflow | < 1.10.1 | 1.10.1 |
| langflow | ≥ 1.0.0, ≤ 1.9.3 |
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.
langflow (PyPI), and the underlying lfx package that ships the component.< 1.10.1.1.10.1 (core fix). Upgrade to >= 1.12.3 for the complete hardening series.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:
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).
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 on their account, or writes to the filesystem / runs OS commands with the service's privileges.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeis_superuser = TruePythonREPLComponent.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())
Any authenticated user could:
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:
get_globals() injects a curated safe_builtins() mapping, removing __import__, eval, exec, compile, open, input, globals/locals/vars, getattr/setattr, etc. (#13397)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)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)sys.modules["os"] through a module's transitive import graph. (#15198)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.
LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false (or LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true) to disable the interpreter entirely.LANGFLOW_SANDBOX_BACKEND for microVM isolation.