CVE-2026-17632: Langflow AST code scanner bypass

CISO Take

IBM Langflow's built-in AST-based Python security scanner — the control meant to block dangerous code when users author custom components or flows — can itself be evaded, letting a low-privileged authenticated user achieve full remote code execution on the server (CVSS 8.8, C:H/I:H/A:H). This isn't a novel attack surface for Langflow: it's a widely deployed open-source LLM/agent orchestration platform where custom Python code execution is a core feature, so the blast radius is anyone running it with more than one trusted user or exposing it to semi-trusted builders. Real-world urgency is currently moderate rather than acute — EPSS sits at 0.45% (top 63rd percentile), it's not in CISA KEV, there's no public exploit or Nuclei template, and CISA SSVC rates it TRACK — but the low bar to exploit (network, low complexity, no user interaction beyond a valid low-priv account) means this should not sit unpatched. Upgrade past 1.10.3 per IBM's advisory, and in the interim restrict who can create/edit custom code components and audit accounts with flow-authoring privileges.

Sources: NVD EPSS CISA KEV ATLAS ibm.com

What is the risk?

High technical severity (CVSS 8.8, full C/I/A impact) but currently low real-world exploitation pressure: EPSS is low (0.45%, 63rd percentile), no CISA KEV listing, no public exploit code, and no Nuclei scanner template exist yet. Attack complexity is low and requires no user interaction, but it does require an authenticated account with at least low privileges — meaning exposure is highest for multi-tenant or loosely access-controlled Langflow deployments where self-registration or broad flow-editing access is enabled. CISA's SSVC decision of TRACK reflects this: worth monitoring and patching on a normal cadence, not an emergency. The core risk is that this defeats a purpose-built security control (the AST scanner), so any organization relying on that scanner as a compensating control for 'safe' custom code execution should treat this as a control failure, not just a bug.

How does the attack unfold?

Initial Access

Attacker obtains a low-privileged authenticated account on a Langflow instance with flow/component-authoring rights.

AML.T0012

Security Control Bypass

Attacker crafts Python code in a custom component that evades the flawed AST-based security scanner meant to block dangerous patterns.

AML.T0107

Code Execution

The unvalidated malicious code executes on the Langflow server with the privileges of the backend service.

AML.T0050

Impact

Attacker achieves full compromise of confidentiality, integrity, and availability of the host, with potential pivot to connected credentials, data sources, and internal infrastructure.

AML.T0112

Initial Access

Attacker obtains a low-privileged authenticated account on a Langflow instance with flow/component-authoring rights.

AML.T0012

Security Control Bypass

Attacker crafts Python code in a custom component that evades the flawed AST-based security scanner meant to block dangerous patterns.

AML.T0107

Code Execution

The unvalidated malicious code executes on the Langflow server with the privileges of the backend service.

AML.T0050

Impact

Attacker achieves full compromise of confidentiality, integrity, and availability of the host, with potential pivot to connected credentials, data sources, and internal infrastructure.

AML.T0112

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Langflow	pip	—	No patch
155.0K Pushed 2d 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.7%

chance of exploitation in 30 days

Higher than 50% 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

1) Upgrade Langflow OSS beyond 1.10.3 per IBM's advisory (https://www.ibm.com/support/pages/node/7282646) as soon as operationally feasible — this is the only complete fix. 2) Until patched, restrict flow/component-authoring privileges to fully trusted users only; disable self-service account creation or custom-code components for lower-trust user tiers. 3) Run Langflow with least-privilege OS/container permissions and network egress restrictions so that even successful code execution has limited blast radius (no direct path to credentials, internal networks, or other services). 4) Monitor for anomalous process spawning, outbound connections, or file writes originating from the Langflow service account/container. 5) Review audit logs for custom component/flow creation or edits by accounts that shouldn't need that capability.

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 Framework Agent Plugin AML.T0050 - Command and Scripting Interpreter AML.T0107 - Exploitation for Defense Evasion

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 is evaluated and documented

OWASP LLM Top 10

LLM08 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-17632?

IBM Langflow's built-in AST-based Python security scanner — the control meant to block dangerous code when users author custom components or flows — can itself be evaded, letting a low-privileged authenticated user achieve full remote code execution on the server (CVSS 8.8, C:H/I:H/A:H). This isn't a novel attack surface for Langflow: it's a widely deployed open-source LLM/agent orchestration platform where custom Python code execution is a core feature, so the blast radius is anyone running it with more than one trusted user or exposing it to semi-trusted builders. Real-world urgency is currently moderate rather than acute — EPSS sits at 0.45% (top 63rd percentile), it's not in CISA KEV, there's no public exploit or Nuclei template, and CISA SSVC rates it TRACK — but the low bar to exploit (network, low complexity, no user interaction beyond a valid low-priv account) means this should not sit unpatched. Upgrade past 1.10.3 per IBM's advisory, and in the interim restrict who can create/edit custom code components and audit accounts with flow-authoring privileges.

Is CVE-2026-17632 actively exploited?

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

How to fix CVE-2026-17632?

1) Upgrade Langflow OSS beyond 1.10.3 per IBM's advisory (https://www.ibm.com/support/pages/node/7282646) as soon as operationally feasible — this is the only complete fix. 2) Until patched, restrict flow/component-authoring privileges to fully trusted users only; disable self-service account creation or custom-code components for lower-trust user tiers. 3) Run Langflow with least-privilege OS/container permissions and network egress restrictions so that even successful code execution has limited blast radius (no direct path to credentials, internal networks, or other services). 4) Monitor for anomalous process spawning, outbound connections, or file writes originating from the Langflow service account/container. 5) Review audit logs for custom component/flow creation or edits by accounts that shouldn't need that capability.

What systems are affected by CVE-2026-17632?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM orchestration / low-code AI pipelines, custom code execution environments.

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

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

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM orchestration / low-code AI pipelinescustom code execution environments

MITRE ATLAS Techniques

AML.T0050 Command and Scripting Interpreter

AML.T0107 Exploitation for Defense Evasion

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

IBM Langflow OSS 1.0.0 through 1.10.3 could allow a remote authenticated attacker to execute arbitrary code due to improper validation of Python code during AST-based security scanning.

Exploitation Scenario

An attacker obtains a low-privileged authenticated account on a Langflow instance — for example via self-registration on a permissively configured deployment, a phished/reused credential, or insider access in an org that grants broad flow-building rights. Instead of writing an obviously malicious custom Python component (which the AST scanner would flag and block), the attacker crafts code that achieves the same effect through patterns the scanner fails to properly validate — such as indirect attribute access, dynamic imports, or alternate code paths to dangerous built-ins. When the flow/component runs, the payload executes with the privileges of the Langflow backend process, giving the attacker a foothold on the host. From there they can exfiltrate connected LLM API keys and credentials, pivot into any data sources or vector stores the instance touches, or use the compromised server as a launch point deeper into the network.

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.