CVE-2026-6598: Langflow cleartext auth storage

Q: Is CVE-2026-6598 actively exploited?

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

Q: How to fix CVE-2026-6598?

1. **Patch immediately**: Upgrade langflow to >= 1.9.1, which resolves cleartext storage in `encrypt_auth_settings`. 2. **Audit existing deployments**: On affected versions (< 1.9.1), inspect the storage paths used by Langflow's project persistence layer for cleartext credential files and rotate any exposed API keys. 3. **Network segmentation**: If immediate patching is blocked, restrict access to the `/api/v1/projects` endpoint to authenticated internal networks only. 4. **Secret management**: Configure Langflow to use a secrets manager (Vault, AWS Secrets Manager) rather than file-based credential storage for production deployments. 5. **Detection**: Monitor filesystem writes to Langflow project directories and alert on any reads of those files by processes other than the Langflow service itself.

Q: What systems are affected by CVE-2026-6598?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM orchestration pipelines, AI workflow automation, multi-tenant AI platforms.

Q: What is the CVSS score for CVE-2026-6598?

CVE-2026-6598 has a CVSS v3.1 base score of 4.3 (MEDIUM). The EPSS exploitation probability is 0.15%.

CISO Take

Langflow's project creation endpoint fails to encrypt authentication settings before writing them to disk — despite the function being named `encrypt_auth_settings` — meaning API keys and service credentials for connected LLM providers are stored in cleartext and readable by any process or user with filesystem access. While the CVSS score is medium (4.3) and the vulnerability is not in CISA's KEV catalog, Langflow deployments typically hold high-value secrets: OpenAI, Anthropic, and similar LLM API keys that grant access to expensive inference capacity and proprietary data. The package carries a risk score of 77/100 with 40 prior CVEs, and a public proof-of-concept gist is already available, lowering the bar for exploitation even as formal exploit tooling remains absent. Organizations should upgrade to Langflow 1.9.1 immediately; if patching is blocked, restrict project creation endpoint access via network policy and audit disk storage paths for cleartext credential files.

Sources: NVD EPSS GitHub Advisory ATLAS

What is the risk?

Risk is moderate despite the medium CVSS score. The actual danger lies in the value of what is stored — LLM API keys — not in the complexity of exploitation, which is trivial for any authenticated low-privilege user. Network exposure with no user interaction required means any Langflow instance reachable from an internal network is vulnerable. The absence of downstream package dependents reduces supply chain blast radius, but the 40 prior CVEs in this package suggest systemic security debt. EPSS probability is very low (0.013%), but the public gist disclosure means adversaries who specifically target Langflow are already equipped.

How does the attack unfold?

Initial Access

Adversary authenticates to a Langflow instance using any low-privilege account obtained through credential stuffing, phishing, or an internal foothold.

AML.T0012

Exploitation

Adversary calls the Project Creation API endpoint (`POST /api/v1/projects`) with authentication settings in the `auth_settings` parameter, triggering the vulnerable `encrypt_auth_settings` function.

AML.T0049

Credential Access

API keys and service credentials are written in cleartext to disk by the flawed function; adversary reads these files via OS access, container escape, or a secondary file read vulnerability.

AML.T0055

Impact

Adversary uses harvested LLM API credentials to make unauthorized inference calls, exfiltrate proprietary prompts and data, or pivot into connected enterprise systems.

AML.T0025

Initial Access

Adversary authenticates to a Langflow instance using any low-privilege account obtained through credential stuffing, phishing, or an internal foothold.

AML.T0012

Exploitation

Adversary calls the Project Creation API endpoint (`POST /api/v1/projects`) with authentication settings in the `auth_settings` parameter, triggering the vulnerable `encrypt_auth_settings` function.

AML.T0049

Credential Access

API keys and service credentials are written in cleartext to disk by the flawed function; adversary reads these files via OS access, container escape, or a secondary file read vulnerability.

AML.T0055

Impact

Adversary uses harvested LLM API credentials to make unauthorized inference calls, exfiltrate proprietary prompts and data, or pivot into connected enterprise systems.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Langflow	pip	< 1.9.1	`1.9.1`
149.9K Pushed 2d ago 40% patched ~67d to patch Full package profile →

Do you use Langflow? You're affected.

How severe is it?

CVSS 3.1

4.3 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 5% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C Low

I None

A None

What should I do?

5 steps

Patch immediately

Upgrade langflow to >= 1.9.1, which resolves cleartext storage in encrypt_auth_settings.
Audit existing deployments

On affected versions (< 1.9.1), inspect the storage paths used by Langflow's project persistence layer for cleartext credential files and rotate any exposed API keys.
Network segmentation

If immediate patching is blocked, restrict access to the /api/v1/projects endpoint to authenticated internal networks only.
Secret management

Configure Langflow to use a secrets manager (Vault, AWS Secrets Manager) rather than file-based credential storage for production deployments.
Detection

Monitor filesystem writes to Langflow project directories and alert on any reads of those files by processes other than the Langflow service itself.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

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

How is it classified?

Data Extraction Privacy Violation Framework AML.T0037 - Data from Local System AML.T0049 - Exploit Public-Facing Application AML.T0055 - Unsecured Credentials AML.T0083 - Credentials from AI Agent Configuration AML.T0106 - Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.8.2 - Data security for AI systems

NIST AI RMF

MANAGE 2.4 - Residual risks are managed

OWASP LLM Top 10

LLM02 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-6598?

Langflow's project creation endpoint fails to encrypt authentication settings before writing them to disk — despite the function being named `encrypt_auth_settings` — meaning API keys and service credentials for connected LLM providers are stored in cleartext and readable by any process or user with filesystem access. While the CVSS score is medium (4.3) and the vulnerability is not in CISA's KEV catalog, Langflow deployments typically hold high-value secrets: OpenAI, Anthropic, and similar LLM API keys that grant access to expensive inference capacity and proprietary data. The package carries a risk score of 77/100 with 40 prior CVEs, and a public proof-of-concept gist is already available, lowering the bar for exploitation even as formal exploit tooling remains absent. Organizations should upgrade to Langflow 1.9.1 immediately; if patching is blocked, restrict project creation endpoint access via network policy and audit disk storage paths for cleartext credential files.

Is CVE-2026-6598 actively exploited?

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

How to fix CVE-2026-6598?

1. **Patch immediately**: Upgrade langflow to >= 1.9.1, which resolves cleartext storage in `encrypt_auth_settings`. 2. **Audit existing deployments**: On affected versions (< 1.9.1), inspect the storage paths used by Langflow's project persistence layer for cleartext credential files and rotate any exposed API keys. 3. **Network segmentation**: If immediate patching is blocked, restrict access to the `/api/v1/projects` endpoint to authenticated internal networks only. 4. **Secret management**: Configure Langflow to use a secrets manager (Vault, AWS Secrets Manager) rather than file-based credential storage for production deployments. 5. **Detection**: Monitor filesystem writes to Langflow project directories and alert on any reads of those files by processes other than the Langflow service itself.

What systems are affected by CVE-2026-6598?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM orchestration pipelines, AI workflow automation, multi-tenant AI platforms.

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

CVE-2026-6598 has a CVSS v3.1 base score of 4.3 (MEDIUM). The EPSS exploitation probability is 0.15%.

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM orchestration pipelinesAI workflow automationmulti-tenant AI platforms

MITRE ATLAS Techniques

AML.T0037 Data from Local System

AML.T0049 Exploit Public-Facing Application

AML.T0055 Unsecured Credentials

AML.T0083 Credentials from AI Agent Configuration

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.8.2

NIST AI RMF: MANAGE 2.4

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

A security vulnerability has been detected in langflow-ai langflow up to 1.8.3. The affected element is the function create_project/encrypt_auth_settings of the file src/backend/base/Langflow/api/v1/projects.py of the component Project Creation Endpoint. Such manipulation of the argument auth_settings leads to cleartext storage in a file or on disk. The attack can be launched remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Exploitation Scenario

An adversary with a valid low-privilege Langflow account — obtained through credential stuffing, phishing, or an existing internal foothold — calls the `POST /api/v1/projects` endpoint and creates a project supplying API credentials in the `auth_settings` parameter. The `encrypt_auth_settings` function stores these credentials in cleartext to disk. The attacker then either directly reads the credential files (if they have OS-level or container access), exploits a separate path traversal or file read vulnerability in Langflow to retrieve the files, or waits for an admin to misconfigure file permissions on the storage directory. With harvested API keys for services like OpenAI, the attacker exfiltrates them and begins unauthorized inference calls — burning budget, accessing proprietary system prompts, or pivoting into connected enterprise data sources.

Weaknesses (CWE)

CWE-312 Cleartext Storage of Sensitive Information Primary CWE-312 Cleartext Storage of Sensitive Information Primary CWE-313 Cleartext Storage in a File or on Disk Primary CWE-313 Cleartext Storage in a File or on Disk Primary

CWE-312 — Cleartext Storage of Sensitive Information: The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.

[Implementation, System Configuration, Operation] When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to encrypt the data at rest. [REF-1297] [REF-1299] [REF-1301]
[Implementation, System Configuration, Operation] In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.

Source: MITRE CWE corpus.