IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper access control.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to improper limitation of a pathname to a restricted directory.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to improper authorization.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to improper access control.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote attacker to execute arbitrary code due to improper neutralization of special elements used in an OS command.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper neutralization of special elements used in code.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote attacker to execute arbitrary code due to improper control of code generation.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote attacker to execute arbitrary code due to an expected dependency confusion.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper control of code generation.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow an attacker with access to the server secret and Redis write access to submit a malicious serialized cache value. When the value was retrieved, deserialization could have executed attacker-controlled code with the privileges of the service process.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper control of generation of code.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper control of code generation.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to improper limitation of a pathname to a restricted directory.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to insufficiently protected credentials.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to exposure of sensitive information to an unauthorized actor.

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.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote attacker to execute arbitrary code due to an incomplete blocklist in the code security scanner.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper input validation.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary OS commands due to improper neutralization of special elements used in an OS command ('Code Injection'), aka improper control of code generation.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper neutralization of special elements used in an OS command ('Code Injection') related to improper input validation.