CVE-2026-19299: Langflow authenticated path

CISO Take

IBM Langflow OSS versions 1.0.0 through 1.11.2 contain a path traversal flaw (CWE-22) that lets any authenticated user — even one with low privileges — read arbitrary files outside the application's intended directory over the network, with no user interaction required. There's no public exploit, no Nuclei template, no EPSS score, and it isn't in CISA KEV, so this looks like a low-noise disclosure rather than an active campaign, but Langflow deployments routinely store API keys, LLM provider credentials, and agent tool configurations inside flow files, so a successful read can hand an attacker secrets that unlock far more than the Langflow instance itself. The requirement for a valid low-privilege account meaningfully raises the bar versus an unauthenticated bug, which is consistent with the medium CVSS score (6.5) and confidentiality-only impact (no integrity or availability loss). Patch to the fixed release referenced in IBM's advisory as soon as it's available, and in the meantime restrict Langflow account provisioning, review any self-service signup or shared low-privilege accounts, and audit access logs for `../` traversal sequences against file-serving endpoints. Treat any deployment with credentials embedded in flow definitions as at-risk and rotate those secrets after patching.

Sources:NVDibm.comATLAS

What is the risk?

Medium severity per CVSS (6.5, AV:N/AC:L/PR:L/UI:N/C:H/I:N/A:N) — network-reachable and low complexity, but gated behind low-privilege authentication, which limits the blast radius to insiders, compromised low-priv accounts, or environments with open self-registration. No EPSS data, no CISA KEV listing, no public PoC, and no Nuclei scanner coverage exist yet, indicating exploitation is currently theoretical rather than observed in the wild. The confidentiality-only impact (no code execution, no write, no DoS) caps the direct damage to information disclosure, but because Langflow flows commonly embed LLM API keys and tool credentials, the practical risk is higher than the raw CVSS suggests for any deployment that hasn't segmented secrets from flow storage.

How does the attack unfold?

Initial Access

Attacker obtains or already holds a valid low-privileged authenticated account on a Langflow instance.

AML.T0012

Exploitation

Attacker sends a crafted request with path traversal sequences to a vulnerable file-handling endpoint to escape the intended storage directory.

AML.T0049

Collection

Attacker reads arbitrary host files, including flow definitions and configs that may embed API keys or credentials.

AML.T0037

Impact

Disclosed credentials and secrets are reused to access connected LLM provider accounts or pivot to other systems, extending the breach beyond the Langflow instance.

AML.T0024

Initial Access

Attacker obtains or already holds a valid low-privileged authenticated account on a Langflow instance.

AML.T0012

Exploitation

Attacker sends a crafted request with path traversal sequences to a vulnerable file-handling endpoint to escape the intended storage directory.

AML.T0049

Collection

Attacker reads arbitrary host files, including flow definitions and configs that may embed API keys or credentials.

AML.T0037

Impact

Disclosed credentials and secrets are reused to access connected LLM provider accounts or pivot to other systems, extending the breach beyond the Langflow instance.

AML.T0024

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Langflow	pip	—	No patch
156.2KPushed yesterday18% patched~66d to patchFull package profile →

Do you use Langflow? You're affected.

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.7%

chance of exploitation in 30 days

Higher than 51% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CHigh

INone

ANone

What should I do?

1 step

1) Upgrade to the Langflow release that fixes this issue per IBM's advisory (https://www.ibm.com/support/pages/node/7285641) as soon as it's confirmed available. 2) Until patched, restrict who can hold low-privilege authenticated accounts on the instance — disable open self-registration and review existing low-priv accounts for necessity. 3) Move secrets (LLM API keys, DB credentials) out of flow definitions and into a secrets manager or environment-scoped config not reachable via the affected file paths. 4) Monitor access/application logs for path traversal indicators (../, encoded traversal sequences, unexpected file paths) hitting file-serving or export endpoints. 5) Network-restrict Langflow instances (VPN/allowlist) to reduce the pool of accounts that could be compromised and used as the low-privilege foothold.

How is it classified?

Data LeakageData ExtractionFrameworkAgentAML.T0037- Data from Local System AML.T0049- Exploit Public-Facing Application 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

ISO 42001

A.6.2.2-AI system security controls

OWASP LLM Top 10

LLM02-Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-19299?

IBM Langflow OSS versions 1.0.0 through 1.11.2 contain a path traversal flaw (CWE-22) that lets any authenticated user — even one with low privileges — read arbitrary files outside the application's intended directory over the network, with no user interaction required. There's no public exploit, no Nuclei template, no EPSS score, and it isn't in CISA KEV, so this looks like a low-noise disclosure rather than an active campaign, but Langflow deployments routinely store API keys, LLM provider credentials, and agent tool configurations inside flow files, so a successful read can hand an attacker secrets that unlock far more than the Langflow instance itself. The requirement for a valid low-privilege account meaningfully raises the bar versus an unauthenticated bug, which is consistent with the medium CVSS score (6.5) and confidentiality-only impact (no integrity or availability loss). Patch to the fixed release referenced in IBM's advisory as soon as it's available, and in the meantime restrict Langflow account provisioning, review any self-service signup or shared low-privilege accounts, and audit access logs for `../` traversal sequences against file-serving endpoints. Treat any deployment with credentials embedded in flow definitions as at-risk and rotate those secrets after patching.

Is CVE-2026-19299 actively exploited?

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

How to fix CVE-2026-19299?

1) Upgrade to the Langflow release that fixes this issue per IBM's advisory (https://www.ibm.com/support/pages/node/7285641) as soon as it's confirmed available. 2) Until patched, restrict who can hold low-privilege authenticated accounts on the instance — disable open self-registration and review existing low-priv accounts for necessity. 3) Move secrets (LLM API keys, DB credentials) out of flow definitions and into a secrets manager or environment-scoped config not reachable via the affected file paths. 4) Monitor access/application logs for path traversal indicators (`../`, encoded traversal sequences, unexpected file paths) hitting file-serving or export endpoints. 5) Network-restrict Langflow instances (VPN/allowlist) to reduce the pool of accounts that could be compromised and used as the low-privilege foothold.

What systems are affected by CVE-2026-19299?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, low-code LLM application builders, multi-tenant LLM orchestration platforms.

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

CVE-2026-19299 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.66%.

What is the AI security impact?

Affected AI Architectures

agent frameworkslow-code LLM application buildersmulti-tenant LLM orchestration platforms

MITRE ATLAS Techniques

AML.T0037Data from Local System

AML.T0049Exploit Public-Facing Application

AML.T0083Credentials from AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.2

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

IBM Langflow OSS 1.0.0 through 1.11.2 could allow a remote authenticated attacker to obtain sensitive information due to path traversal.

Exploitation Scenario

An attacker obtains or is granted a low-privileged Langflow account — via self-registration, a shared team invite, or credential compromise of a junior team member. Using that valid session, they send a crafted request containing path traversal sequences to a vulnerable file-handling endpoint (e.g., a flow export/import or media-serving route), escaping the intended storage directory. This lets them read arbitrary files on the host filesystem, including other users' flow JSON files or environment configuration containing embedded LLM provider API keys and tool credentials. The attacker then reuses those harvested credentials to access the organization's LLM provider account directly, run up usage costs, or pivot to other systems the exposed credentials touch — all without ever needing elevated Langflow privileges or executing code on the host.

Weaknesses (CWE)

CWE-22Improper Limitation of a Pathname to a Restricted DirectoryPrimary CWE-22Improper Limitation of a Pathname to a Restricted Directory

CWE-22 — Improper Limitation of a Pathname to a Restricted Directory: The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.