| Gói / sản phẩm | Phiên bản bị ảnh hưởng | Phiên bản đã vá |
|---|---|---|
| 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.
Bạn đang dùng một trong các sản phẩm này? Quét site để biết có đang lộ phiên bản có lỗ hổng không.
Quét site miễn phíis_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.