CVE-2026-8470: Langflow weak PRNG lets attackers

CISO Take

IBM Langflow's open-source flow-building framework derives Fernet encryption keys for stored secrets using Python's non-cryptographic `random` module instead of a CSPRNG, so any secret shorter than 32 characters produces a deterministic, replayable key via the Mersenne Twister algorithm. This is critical in severity (CVSS 9.1, network-exploitable, no privileges or user interaction required) because it directly undermines the confidentiality of API keys and authentication tokens Langflow stores on behalf of connected LLM providers, vector databases, and third-party integrations — a full secrets-vault compromise, not a peripheral bug. Actual exploitation risk is currently low: EPSS sits at 0.11%, there is no CISA KEV listing, no public exploit or Nuclei template, and CISA's SSVC decision is TRACK (lowest urgency tier), so this reads as a design flaw awaiting a reliable exploit chain rather than an in-the-wild campaign. Given the blast radius if that changes, patch to a fixed Langflow release beyond 1.10.3 immediately, and treat any secret ever stored under vulnerable versions as compromised — rotate all API keys, tokens, and credentials configured in affected Langflow instances regardless of whether exploitation is confirmed.

Sources: NVD EPSS ATLAS ibm.com

What is the risk?

High potential impact, low current observed exploitation. The flaw is trivially reproducible once an attacker knows (or can brute-force) the short user secret and replicate Python's Mersenne Twister state — no exotic tooling required, only knowledge of how Fernet keys are derived. However, exploitation requires the attacker to already have some path to the seed/secret material or to the encrypted blob itself, which narrows real-world exposure to Langflow deployments that are network-reachable or where an attacker has partial internal access. The absence of KEV listing, public PoC, and scanner coverage, plus a very low EPSS score, indicate this has not yet been weaponized at scale — but the CVSS 9.1 rating reflects how severe a successful attack would be, not how likely it currently is.

How does the attack unfold?

Discovery

Attacker identifies a Langflow deployment configured with a secret under 32 characters, either via reconnaissance or partial internal access.

AML.T0006

Key reconstruction

Attacker replicates Python's deterministic Mersenne Twister PRNG output from the known/guessable seed to derive the same Fernet encryption key.

Credential decryption

Attacker uses the reconstructed key to decrypt Langflow's stored API keys and authentication tokens.

AML.T0055

Downstream compromise

Attacker authenticates to connected LLM providers, vector databases, or third-party services using the stolen credentials.

AML.T0012

Discovery

Attacker identifies a Langflow deployment configured with a secret under 32 characters, either via reconnaissance or partial internal access.

AML.T0006

Key reconstruction

Attacker replicates Python's deterministic Mersenne Twister PRNG output from the known/guessable seed to derive the same Fernet encryption key.

Credential decryption

Attacker uses the reconstructed key to decrypt Langflow's stored API keys and authentication tokens.

AML.T0055

Downstream compromise

Attacker authenticates to connected LLM providers, vector databases, or third-party services using the stolen credentials.

AML.T0012

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Langflow	pip	—	No patch
154.7K Pushed 7d ago 17% patched ~70d to patch Full package profile →

Do you use Langflow? You're affected.

How severe is it?

CVSS 3.1

9.1 / 10

EPSS

0.1%

chance of exploitation in 30 days

Higher than 1% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C None

I High

A High

What should I do?

1 step

1) Upgrade Langflow beyond 1.10.3 to the version where the fix (proper CSPRNG-based key derivation, e.g. secrets module or os.urandom) is applied — confirm the fixed version via the IBM advisory. 2) Immediately rotate all API keys, tokens, and credentials stored in any Langflow instance that ran a vulnerable version, since past encryption cannot be trusted retroactively. 3) As an interim workaround, ensure the secret used for Fernet key generation is at least 32 characters and high-entropy, which changes the derivation path in the vulnerable versions (verify this is actually effective for your version before relying on it). 4) Restrict network exposure of Langflow admin/API endpoints to trusted networks only. 5) For detection, audit access logs for unexpected decryption activity or credential use from unfamiliar IPs/services tied to secrets that were ever stored in Langflow.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Leakage Privacy Violation Framework AML.T0012 - Valid Accounts AML.T0055 - Unsecured Credentials AML.T0083 - Credentials from AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MEASURE 2.7 - AI system security and resilience evaluation

OWASP LLM Top 10

LLM02 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-8470?

IBM Langflow's open-source flow-building framework derives Fernet encryption keys for stored secrets using Python's non-cryptographic `random` module instead of a CSPRNG, so any secret shorter than 32 characters produces a deterministic, replayable key via the Mersenne Twister algorithm. This is critical in severity (CVSS 9.1, network-exploitable, no privileges or user interaction required) because it directly undermines the confidentiality of API keys and authentication tokens Langflow stores on behalf of connected LLM providers, vector databases, and third-party integrations — a full secrets-vault compromise, not a peripheral bug. Actual exploitation risk is currently low: EPSS sits at 0.11%, there is no CISA KEV listing, no public exploit or Nuclei template, and CISA's SSVC decision is TRACK (lowest urgency tier), so this reads as a design flaw awaiting a reliable exploit chain rather than an in-the-wild campaign. Given the blast radius if that changes, patch to a fixed Langflow release beyond 1.10.3 immediately, and treat any secret ever stored under vulnerable versions as compromised — rotate all API keys, tokens, and credentials configured in affected Langflow instances regardless of whether exploitation is confirmed.

Is CVE-2026-8470 actively exploited?

No confirmed active exploitation of CVE-2026-8470 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-8470?

1) Upgrade Langflow beyond 1.10.3 to the version where the fix (proper CSPRNG-based key derivation, e.g. `secrets` module or `os.urandom`) is applied — confirm the fixed version via the IBM advisory. 2) Immediately rotate all API keys, tokens, and credentials stored in any Langflow instance that ran a vulnerable version, since past encryption cannot be trusted retroactively. 3) As an interim workaround, ensure the secret used for Fernet key generation is at least 32 characters and high-entropy, which changes the derivation path in the vulnerable versions (verify this is actually effective for your version before relying on it). 4) Restrict network exposure of Langflow admin/API endpoints to trusted networks only. 5) For detection, audit access logs for unexpected decryption activity or credential use from unfamiliar IPs/services tied to secrets that were ever stored in Langflow.

What systems are affected by CVE-2026-8470?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM workflow orchestration platforms, credential/secrets storage in AI pipelines.

What is the CVSS score for CVE-2026-8470?

CVE-2026-8470 has a CVSS v3.1 base score of 9.1 (CRITICAL). The EPSS exploitation probability is 0.11%.

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM workflow orchestration platformscredential/secrets storage in AI pipelines

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0055 Unsecured Credentials

AML.T0083 Credentials from AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker identifies an internet-facing or internally reachable Langflow instance and obtains (via a separate access vector, misconfiguration, or insider position) the encrypted secrets blob and the short configuration secret used to seed key generation. Because Python's `random` module is deterministic and seedable, the attacker reconstructs the exact Mersenne Twister output sequence used to build the Fernet key, decrypts the stored blob, and recovers plaintext API keys and auth tokens for every LLM provider, vector database, or third-party service the Langflow flows were configured to call. The attacker then uses those harvested credentials directly against the downstream AI services — running up API bills, exfiltrating data through connected model providers, or pivoting into other systems that trusted those tokens.

Weaknesses (CWE)

CWE-327 Use of a Broken or Risky Cryptographic Algorithm Primary CWE-327 Use of a Broken or Risky Cryptographic Algorithm

CWE-327 — Use of a Broken or Risky Cryptographic Algorithm: The product uses a broken or risky cryptographic algorithm or protocol.

[Architecture and Design] When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis. For example, US government systems require FIPS 140-2 certification [REF-1192]. Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak. Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267
[Architecture and Design] Ensure that the design allows one cryptographic algorithm to be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.

Source: MITRE CWE corpus.