CVE-2026-9202: Langflow: unauth signup chains to RCE

CRITICAL
Published July 17, 2026
CISO Take

Langflow OSS versions 1.0.0 through 1.10.0 let anyone with network access create unlimited user accounts without authentication, and on instances running the documented NEW_USER_IS_ACTIVE=true setting those accounts become active immediately, giving the attacker a working login that reaches Langflow's remote code execution endpoints without ever needing AUTO_LOGIN enabled. This is a maximum-severity flaw (CVSS 9.8, network vector, no privileges or user interaction required) in a framework already carrying 69 other recorded CVEs and a 77/100 package risk score, and while it is not yet listed in CISA KEV and has no public exploit or Nuclei scanner template today, the trivial complexity and IBM's own vendor advisory make weaponization straightforward for anyone who fingerprints an exposed Langflow instance. Because Langflow is commonly self-hosted to power internal AI agent and RAG pipelines, a single unauthenticated HTTP request can escalate directly to full compromise of whatever workflow or agent infrastructure it runs. Patch to the version specified in IBM's advisory immediately, and until patched treat NEW_USER_IS_ACTIVE=true as a critical misconfiguration to disable, put Langflow behind SSO/AUTO_LOGIN and network restrictions, and monitor the user table for anomalous account creation as a compensating detection control.

Sources: NVD CISA KEV ATLAS ibm.com

What is the risk?

Critical risk: CVSS 9.8 with network attack vector, no privileges required, no user interaction, and full confidentiality/integrity/availability impact. Exploitation requires only two trivial steps (create an account, log in) before reaching pre-existing RCE endpoints, so attack complexity is effectively low despite no current public PoC, Nuclei template, or KEV listing. The absence of an EPSS score and KEV entry means opportunistic mass exploitation has not yet been observed, but the combination of missing authentication (CWE-306) and a well-documented misconfiguration (NEW_USER_IS_ACTIVE=true) makes this a near-zero-skill exploit chain for any internet-facing Langflow deployment.

How does the attack unfold?

Establish Account
Attacker sends an unauthenticated request to Langflow's user creation endpoint to register a new account on the exposed instance.
AML.T0021
Authenticate
Because the instance runs NEW_USER_IS_ACTIVE=true, the newly created account is active immediately and the attacker logs in without needing AUTO_LOGIN or admin approval.
AML.T0012
Exploit RCE Endpoint
Using the authenticated session, the attacker invokes Langflow endpoints that support arbitrary code execution within flow components.
AML.T0050
Host Compromise
Arbitrary code execution on the Langflow host exposes connected LLM API keys, vector stores, and agent tool integrations, giving the attacker a foothold for further compromise.
AML.T0112

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Langflow pip No patch
151.7K Pushed 5d ago 34% patched ~70d to patch Full package profile →

Do you use Langflow? You're affected.

How severe is it?

CVSS 3.1
9.8 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI None
S Unchanged
C High
I High
A High

What should I do?

1 step
  1. 1) Patch to the fixed Langflow version referenced in IBM's advisory (ibm.com/support/pages/node/7278929) as soon as it is validated in a test environment. 2) Immediately audit configuration for NEW_USER_IS_ACTIVE=true and disable it, or require admin approval for new accounts, until patched. 3) Enforce AUTO_LOGIN/SSO in front of Langflow and restrict network exposure to trusted/internal networks only — do not expose the signup or admin endpoints to the open internet. 4) Detection: alert on unexpected new-user creation events and logins from unfamiliar accounts in Langflow's user table/audit logs, and review recent account creations retroactively for signs of prior exploitation.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, Robustness and Cybersecurity
ISO 42001
Annex A.6.2 - AI system security controls
NIST AI RMF
MANAGE-4.1 - AI system incident response, recovery, and monitoring

Frequently Asked Questions

What is CVE-2026-9202?

Langflow OSS versions 1.0.0 through 1.10.0 let anyone with network access create unlimited user accounts without authentication, and on instances running the documented NEW_USER_IS_ACTIVE=true setting those accounts become active immediately, giving the attacker a working login that reaches Langflow's remote code execution endpoints without ever needing AUTO_LOGIN enabled. This is a maximum-severity flaw (CVSS 9.8, network vector, no privileges or user interaction required) in a framework already carrying 69 other recorded CVEs and a 77/100 package risk score, and while it is not yet listed in CISA KEV and has no public exploit or Nuclei scanner template today, the trivial complexity and IBM's own vendor advisory make weaponization straightforward for anyone who fingerprints an exposed Langflow instance. Because Langflow is commonly self-hosted to power internal AI agent and RAG pipelines, a single unauthenticated HTTP request can escalate directly to full compromise of whatever workflow or agent infrastructure it runs. Patch to the version specified in IBM's advisory immediately, and until patched treat NEW_USER_IS_ACTIVE=true as a critical misconfiguration to disable, put Langflow behind SSO/AUTO_LOGIN and network restrictions, and monitor the user table for anomalous account creation as a compensating detection control.

Is CVE-2026-9202 actively exploited?

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

How to fix CVE-2026-9202?

1) Patch to the fixed Langflow version referenced in IBM's advisory (ibm.com/support/pages/node/7278929) as soon as it is validated in a test environment. 2) Immediately audit configuration for NEW_USER_IS_ACTIVE=true and disable it, or require admin approval for new accounts, until patched. 3) Enforce AUTO_LOGIN/SSO in front of Langflow and restrict network exposure to trusted/internal networks only — do not expose the signup or admin endpoints to the open internet. 4) Detection: alert on unexpected new-user creation events and logins from unfamiliar accounts in Langflow's user table/audit logs, and review recent account creations retroactively for signs of prior exploitation.

What systems are affected by CVE-2026-9202?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM application frameworks, self-hosted AI workflow builders, RAG pipelines.

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

CVE-2026-9202 has a CVSS v3.1 base score of 9.8 (CRITICAL).

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM application frameworksself-hosted AI workflow buildersRAG pipelines

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0021 Establish Accounts
AML.T0049 Exploit Public-Facing Application
AML.T0050 Command and Scripting Interpreter

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: Annex A.6.2
NIST AI RMF: MANAGE-4.1

What are the technical details?

Original Advisory

IBM Langflow OSS 1.0.0 through 1.10.0 allows unauthenticated attackers to create unlimited user accounts on any Langflow instance; when NEW_USER_IS_ACTIVE=true (documented deployment option), newly created accounts are immediately active and can authenticate to reach RCE endpoints, bypassing the need for AUTO_LOGIN.

Exploitation Scenario

An attacker scans for internet-exposed Langflow instances (e.g., via Shodan/fingerprinting), sends an unauthenticated request to the account creation endpoint to register a new user, and — because the instance runs the common NEW_USER_IS_ACTIVE=true configuration — is granted an immediately active account without any approval step. The attacker logs in with the newly created credentials and calls one of Langflow's authenticated RCE-capable endpoints (e.g., custom component/code execution features intended for legitimate flow builders), gaining arbitrary code execution on the host and pivoting to any connected LLM API keys, vector stores, or internal tools wired into the agent workflows running on that instance.

Weaknesses (CWE)

CWE-306 — Missing Authentication for Critical Function: The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

  • [Architecture and Design] Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability. Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port. In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate
  • [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.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

References

Timeline

Published
July 17, 2026
Last Modified
July 17, 2026
First Seen
July 17, 2026

Related Vulnerabilities