CVE-2026-79742: Langflow RCE — HIGH

CISO Take

IBM Langflow OSS versions 1.0.0 through 1.11.5 ship a code-execution sandbox whose environment variable blocklist is incomplete, letting an already-authenticated low-privileged user escape it to run arbitrary code on the host. This matters because Langflow is a widely deployed low-code framework for building LLM/agent pipelines, and a successful exploit gives an attacker full compromise of confidentiality, integrity, and availability (CVSS 8.8) on whatever system runs the flow engine — including any credentials, API keys, or connected data stores reachable from that host. There is no EPSS score, CISA KEV listing, public exploit, or Nuclei template yet, so this is not currently being mass-exploited, but the low bar for entry (any authenticated account, no user interaction, network-reachable, low attack complexity) makes it an attractive target once Langflow instances are indexed by scanners. Prioritize patching to a release beyond 1.11.5 immediately, and in the interim restrict who can create or execute flows/components, audit any user-controlled environment variable inputs, and monitor Langflow hosts for anomalous process spawning or outbound connections originating from the flow-execution process.

Sources: NVD ATLAS ibm.com

What is the risk?

High severity (CVSS 8.8) with low attack complexity and no user interaction required, but exploitability is gated by a prerequisite: the attacker must already hold valid, albeit low-privileged, credentials on the target Langflow instance. That materially lowers real-world risk relative to an unauthenticated RCE, but Langflow deployments commonly grant broad internal access (dev teams, data scientists, shared multi-tenant instances) where low-privileged accounts are easy to obtain via phishing, credential reuse, or default onboarding. No EPSS score, KEV listing, or public PoC exists at time of publication, indicating exploitation is not yet observed in the wild — but the vulnerability class (incomplete blocklist / sandbox escape) is well understood and straightforward to weaponize once researchers or attackers reverse-engineer the patch diff.

How does the attack unfold?

Authenticated Access

Attacker obtains or already holds low-privileged, authenticated credentials to a Langflow instance.

AML.T0012

Blocklist Bypass

Attacker crafts a flow/component that references environment variables not covered by the incomplete blocklist.

AML.T0050

Code Execution

The crafted component executes arbitrary code within the Langflow runtime, escaping the intended sandbox.

AML.T0050

Impact

Attacker harvests credentials/secrets reachable by the process and pivots to connected systems, achieving full compromise of confidentiality, integrity, and availability.

AML.T0083

Authenticated Access

Attacker obtains or already holds low-privileged, authenticated credentials to a Langflow instance.

AML.T0012

Blocklist Bypass

Attacker crafts a flow/component that references environment variables not covered by the incomplete blocklist.

AML.T0050

Code Execution

The crafted component executes arbitrary code within the Langflow runtime, escaping the intended sandbox.

AML.T0050

Impact

Attacker harvests credentials/secrets reachable by the process and pivots to connected systems, achieving full compromise of confidentiality, integrity, and availability.

AML.T0083

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

8.8 / 10

EPSS

0.6%

chance of exploitation in 30 days

Higher than 45% 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 Low

UI None

S Unchanged

C High

I High

A High

What should I do?

1 step

Upgrade Langflow OSS to the first release after 1.11.5 that fixes the environment variable blocklist (verify the exact patched version against the vendor advisory at ibm.com/support/pages/node/7286666 before deploying). Until patched, restrict flow-creation and component-execution privileges to trusted, need-to-know users only, and avoid exposing Langflow instances with self-service account creation to broad internal populations. Rotate any secrets stored as environment variables accessible to the Langflow process, and consider running Langflow in a hardened container/sandbox (non-root, minimal env, network egress restrictions) as defense-in-depth regardless of patch status. Detection: monitor for unexpected child processes, shell invocations, or outbound network connections originating from the Langflow service, and review flow/component creation audit logs for env-var manipulation patterns.

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?

Code Execution Data Leakage Framework Agent AML.T0012 - Valid Accounts AML.T0050 - Command and Scripting Interpreter 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.6 - AI system deployment

NIST AI RMF

MEASURE-2.7 - AI system security and resilience are evaluated and documented

OWASP LLM Top 10

LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-79742?

IBM Langflow OSS versions 1.0.0 through 1.11.5 ship a code-execution sandbox whose environment variable blocklist is incomplete, letting an already-authenticated low-privileged user escape it to run arbitrary code on the host. This matters because Langflow is a widely deployed low-code framework for building LLM/agent pipelines, and a successful exploit gives an attacker full compromise of confidentiality, integrity, and availability (CVSS 8.8) on whatever system runs the flow engine — including any credentials, API keys, or connected data stores reachable from that host. There is no EPSS score, CISA KEV listing, public exploit, or Nuclei template yet, so this is not currently being mass-exploited, but the low bar for entry (any authenticated account, no user interaction, network-reachable, low attack complexity) makes it an attractive target once Langflow instances are indexed by scanners. Prioritize patching to a release beyond 1.11.5 immediately, and in the interim restrict who can create or execute flows/components, audit any user-controlled environment variable inputs, and monitor Langflow hosts for anomalous process spawning or outbound connections originating from the flow-execution process.

Is CVE-2026-79742 actively exploited?

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

How to fix CVE-2026-79742?

Upgrade Langflow OSS to the first release after 1.11.5 that fixes the environment variable blocklist (verify the exact patched version against the vendor advisory at ibm.com/support/pages/node/7286666 before deploying). Until patched, restrict flow-creation and component-execution privileges to trusted, need-to-know users only, and avoid exposing Langflow instances with self-service account creation to broad internal populations. Rotate any secrets stored as environment variables accessible to the Langflow process, and consider running Langflow in a hardened container/sandbox (non-root, minimal env, network egress restrictions) as defense-in-depth regardless of patch status. Detection: monitor for unexpected child processes, shell invocations, or outbound network connections originating from the Langflow service, and review flow/component creation audit logs for env-var manipulation patterns.

What systems are affected by CVE-2026-79742?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM orchestration pipelines, RAG pipelines.

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

CVE-2026-79742 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.55%.

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM orchestration pipelinesRAG pipelines

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0050 Command and Scripting Interpreter

AML.T0083 Credentials from AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MEASURE-2.7

OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

IBM Langflow OSS 1.0.0 through 1.11.5 could allow a remote authenticated attacker to execute arbitrary code due to an incomplete environment variable blocklist.

Exploitation Scenario

An attacker obtains low-privileged credentials to a shared Langflow instance — via a phished internal user, a leaked API key, or a self-service signup on an under-restricted deployment. Using their authenticated session, they build or modify a flow component that references environment variables the blocklist was supposed to restrict, bypassing the incomplete filter to inject and execute arbitrary code within the Langflow runtime. From there they harvest cloud credentials, LLM API keys, and RAG data-source connection strings available to the process, then pivot to connected systems (vector databases, internal APIs, cloud accounts) for further compromise or data exfiltration.

Weaknesses (CWE)

CWE-94 Improper Control of Generation of Code ('Code Injection') Primary CWE-94 Improper Control of Generation of Code ('Code Injection')

CWE-94 — Improper Control of Generation of Code ('Code Injection'): The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

[Architecture and Design] Refactor your program so that you do not have to dynamically generate code.
[Architecture and Design] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.