Langflow: four more code-execution and credential-theft advisories reach the GitHub Advisory Database on 2026-10-05/06, each already months old on IBM's PSIRT page — PythonREPLComponent runs with full builtins (CVE-2026-10561, IBM 10.0 unauthenticated / vendor 9.9 authenticated), the webhook endpoint skips the API key when WEBHOOK_AUTH_ENABLE is left at its False default (CVE-2026-8505, 9.8), the Fernet key that protects every stored credential is derived from random.seed() (CVE-2026-9205, IBM 7.4 / NVD 9.8 / vendor 9.1), and Smart Transform eval()s an LLM-written lambda (CVE-2026-7700, prompt injection to RCE, vendor 8.8 / VulDB 6.3); IBM and the vendor disagree on affected and fixed versions for three of the four

View raw markdownEdit on GitHub ↗

TL;DR

Between 2026-10-05 and 10-06 the GitHub Advisory Database's reviewed pip critical listing picked up three Langflow advisories and its llm listing a fourth. None is new: the vendor published them on its own advisory tab between 2026-08-04 and 09-28, and IBM — which owns Langflow and acts as CNA for three of the four — had bulletins out between 2026-06-21 and 08-05. This repo tracks nine other Langflow advisories and missed these because every prior sweep grepped the product name, found hits, and stopped (LEARNINGS.md §15). The four, with the disagreements preserved:

Bug Ids Vendor GHSA (affected → fixed, score) IBM PSIRT (affected → fixed, score) NVD
PythonREPLComponent runs with the full builtins module — get_globals() built a restricted globals dict but never set __builtins__, so exec() supplied the real one; __import__, open, eval were all reachable GHSA-8qpj-27x8-pwpq / CVE-2026-10561 < 1.10.1 → 1.10.1 ("enhanced hardening through 1.12.3"); 9.9, authenticated user; vendor page dated 2026-09-28 1.0.0–1.9.3 → 1.9.4; 10.0, unauthenticated, because the default LANGFLOW_AUTO_LOGIN=true hands any network caller a superuser JWT; bulletin 2026-06-21 CNA IBM 10.0, published 2026-06-22, Analyzed
Webhook endpoint executes any flow without an API key when WEBHOOK_AUTH_ENABLE is False — which was the default; the handler "returns the flow owner WITHOUT checking the API Key in the request," so a flow UUID is the only secret GHSA-cf6m-vc3m-7cgm / CVE-2026-8505 ≥ 1.7.0, ≤ 1.9.0 → 1.9.1 (PR #12845 flips the default to True); 9.8; vendor page 2026-08-12 1.0.0–1.10.0 → 1.10.1; 9.8; bulletin 2026-07-02 CNA IBM 9.8, published 2026-07-17
Fernet key derived from random.seed(SECRET_KEY) — Mersenne Twister, not a KDF; for a SECRET_KEY under 32 characters the key is fully deterministic, and for longer ones the raw material becomes the key, so whoever reads the secret-key file "can reconstruct the exact Fernet key offline and decrypt every credential stored in the database" (provider API keys, DB passwords, OAuth tokens, webhook secrets, every user) GHSA-jxw3-mjmx-3pqm / CVE-2026-9205 ≤ 1.10.0 → 1.10.1; 9.1 (3.1, AC:L); vendor page 2026-08-12 1.0.0–1.10.3 → 1.11.0; 7.4 (AC:H), bundled with CVE-2026-8470 (same bug class, 7.4), CVE-2026-10128 and CVE-2026-17629; bulletin 2026-08-05, modified 08-24 CNA IBM 7.4 and NVD's own 9.8, published 2026-08-05
Smart Transform (LambdaFilterComponent) eval()s the lambda an LLM wrote — the only validation was "starts with lambda and contains :," then the string ran with full builtins; the attacker's path is the data the model summarises (prompt injection) or the component instructions GHSA-9fpm-3445-2vx4 / CVE-2026-7700 ≥ 1.3.0, < 1.10.3 → 1.10.3 (backport; 1.11.0 mainline); 8.8 High; vendor page 2026-08-04; reporters Peyton Kennedy (Endor Labs), SZXSec, cyjhhh, 0gur1, ajm4n not an IBM record CNA VulDB: 6.3 (3.1) / 2.1 (4.0), published 2026-05-03 — the earliest date in the row

What to run: the vendor's upper bound across the four is 1.10.3, IBM's is 1.11.0, and the vendor's own hardening note for the REPL component points at ≥ 1.12.3; the registry's latest is 1.12.4 (pip index versions langflow, 2026-10-06). Pin ≥ 1.11.0 at minimum and prefer 1.12.4. Then rotate every credential Langflow ever stored if a SECRET_KEY file, a database dump or a backup has left the box — the Fernet bug makes an old backup plus an old secret key a complete credential store, regardless of the version you run today.

What happened

The disagreements are the finding. This repo's rule is to preserve version conflicts rather than pick a side (SKILL.md, accuracy bar §9), and this batch has three:

  • CVE-2026-10561. IBM's bulletin says unauthenticated, 1.0.0–1.9.3, fixed 1.9.4, CVSS 10.0, and explains the unauthenticated part: the REPL component bug combined with the LANGFLOW_AUTO_LOGIN=true default — the same free superuser token this repo covers as CVE-2026-9198. The vendor's advisory, published three months later, scopes the same CVE id to the component alone: authenticated, < 1.10.1, 9.9. The two are describing one root cause (the missing __builtins__ = {}) with and without the auth-bypass chained in front. Neither statement is wrong; a reader on 1.9.4 should know that the vendor does not call that version fixed, and a reader on 1.10.1 should know the vendor's own remediation list ("restricted builtins mapping, AST validation, server-policy enforcement, allow-listed module proxies, optional LANGFLOW_SANDBOX_BACKEND") kept landing through 1.12.3.
  • CVE-2026-8505. The vendor says the vulnerable window opened at 1.7.0 and closed at 1.9.1 with the default flipped; IBM says 1.0.0 through 1.10.0, fixed 1.10.1. The IBM range is a superset; the fix commit is the same PR. If you are on 1.9.1–1.10.0, you are fixed by the vendor's reading and not by IBM's.
  • CVE-2026-9205. Three scores — IBM 7.4 (it rates the attack complexity High, because the attacker needs the secret-key file first), NVD 9.8, the vendor 9.1 — and two fix versions (1.10.1 vendor, 1.11.0 IBM). The IBM bulletin bundles a second id for what reads as the same bug, CVE-2026-8470 ("non-cryptographic random module used for generating Fernet encryption keys"), which neither the vendor tab nor the database lists; it is recorded here from IBM's page only, not opened separately.

Why the database dates are a trap. The reviewed listing shows "Oct 5" and "Oct 6" for advisories whose vendor pages are dated August and September and whose CVE records are from May through August. Sorting the database by publication date made a four-month-old batch look like breaking news; the dates above are the vendor's and IBM's, per LEARNINGS.md ("a GHSA database publication date is not a disclosure date").

The prompt-injection one. CVE-2026-7700 is the entry most specific to this audience: Smart Transform asks a model to write a Python lambda that filters or reshapes the data flowing through the pipeline, then eval()s it. Whoever controls the data — a web page the flow fetched, a document a user uploaded, a row in a table — can steer the model into writing a lambda that is not a filter. The fix (commits 1641b28f in 1.11.0, 94859df3 backported to 1.10.3) validates the generated code; the structural problem, a model's output executed as code in the server process, is the pattern this repo tracks across the Ro1ME agent-framework wave.

Am I affected?

pip show langflow 2>/dev/null | grep -i ^version        # anything < 1.11.0 → yes (IBM); < 1.10.3 → yes (vendor)
# Webhook auth default (fixed builds default to true):
printenv WEBHOOK_AUTH_ENABLE
# Secret key length — < 32 chars makes CVE-2026-9205's key fully deterministic:
python3 -c "import os;print(len(os.environ.get('LANGFLOW_SECRET_KEY','')))"
ls -la ~/.cache/langflow/secret_key 2>/dev/null          # the file the vendor advisory names as the seed source
# Flows using the affected components:
grep -rl 'PythonREPLComponent\|PythonREPLToolComponent\|LambdaFilterComponent' ~/.cache/langflow 2>/dev/null

Also affected if the instance is on 1.11.0+ but a database backup or secret_key file from before the upgrade exists anywhere an attacker could have read it — the Fernet key for that backup is still derivable.

If you are affected

  1. Upgrade to 1.12.4 (or at least 1.11.0, the highest "fixed" version any source gives). Set WEBHOOK_AUTH_ENABLE=true explicitly and LANGFLOW_AUTO_LOGIN=false regardless of version.
  2. Rotate every provider key, database password, OAuth token and webhook secret stored in Langflow — rotating-cloud-credentials.md. The vendor advisory for CVE-2026-9205 says a leaked secret key decrypts "every credential stored in the database" for every user; assume any historical exposure of the key or the database counts.
  3. Regenerate SECRET_KEY with 32+ random bytes after upgrading; the fixed version derives the Fernet key properly, but a short key is still a short key.
  4. Audit flow executions on the webhook endpoint for the window you ran 1.7.0–1.9.0 (vendor) or ≤ 1.10.0 (IBM) with the default auth setting: unexpected callers to /api/v1/webhook/<flow_id> and flows that contain code-execution components — if-your-webapp-was-compromised.md.
  5. For CVE-2026-10561, treat the host as compromised if the instance was internet-reachable with auto-login on; IBM's impact statement is OS command execution at the backend process's privilege, root in the default Docker image.

Prevention

  • Langflow has now accumulated thirteen advisory files in this repo; it is a workflow engine whose components execute Python by design. Run it only behind authentication you control, never with LANGFLOW_AUTO_LOGIN=true, and never with the Python REPL or Smart Transform components enabled on an instance that processes untrusted data — prevention/agent-sandboxing.md.
  • Watch both the vendor tab and the owner's PSIRT page: IBM's bulletins led the vendor's advisories by one to three months on every row above, and the vendor's led the database by one to two months — prevention/supply-chain-attack-surface.md.
  • Treat a secret-key file as equivalent to the credential store it protects; back it up, rotate it, and never derive encryption keys with random.seed() in your own code either.

Why this matters for vibe coders

Langflow is what a generated "AI backend" often turns out to be: a visual flow with a webhook in front and provider keys stored inside. Three of these four bugs do not need a login — one because the webhook default skipped the key check, one because auto-login issued a superuser token, one because the encryption key came from a non-cryptographic PRNG seeded with a string someone typed into a .env — and the fourth is the model being asked to write code and the server running it. Every one of those is a default an agent would have left in place.

Sources