AI Threat Alert
CVE-2026-9103: Langflow: unauth request grants superuser token
CRITICALIBM Langflow's /api/v1/login/auto_login endpoint hands out long-lived superuser bearer tokens to anyone who asks, no credentials required, because the AUTO_LOGIN setting is enabled by default in every OSS deployment from 1.0.0 to 1.10.0. Any network attacker who can reach the instance gets full administrative control over the platform in a single unauthenticated request (CVSS 9.8, AV:N/AC:L/PR:N/UI:N), and permissive CORS settings compound the exposure by letting those tokens leak to untrusted origins in browser-based attacks. This is not a novel AI attack technique — it's a textbook broken-authentication bug (CWE-306) sitting in front of an AI orchestration platform that typically holds embedded LLM API keys, connected data sources, and executable agent flows. There is no EPSS or KEV signal yet since this was just published, but the trivial exploitability and default-on misconfiguration make it a prime target for opportunistic internet scanning. Patch to a fixed IBM Langflow release immediately, or at minimum set AUTO_LOGIN=false and take internet-facing instances off public exposure until patched, then rotate any credentials stored in Langflow flows and lock down CORS to trusted origins.
What is the risk?
Critical. Exploitation requires no authentication, no user interaction, and low complexity — a single crafted HTTP request to a known endpoint yields a superuser token. Because AUTO_LOGIN is enabled by default, most out-of-the-box Langflow deployments are vulnerable unless an operator explicitly disabled it. Combined with permissive CORS, the flaw also enables token theft via malicious web content against admins browsing while authenticated. The absence of a public exploit or Nuclei template today does not reduce urgency: the endpoint and behavior are now public knowledge in the advisory, and mass scanning for exposed Langflow instances is a realistic near-term threat given the framework's popularity for building AI agents and RAG pipelines.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Langflow | pip | — | No patch |
Do you use Langflow? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
1) Upgrade to the IBM-patched Langflow release referenced in the vendor advisory (https://www.ibm.com/support/pages/node/7278926) as soon as it is available. 2) Immediately set AUTO_LOGIN=false in any internet-facing or otherwise untrusted-network deployment — this closes the unauthenticated token issuance path even before patching. 3) Restrict network exposure of the Langflow admin/API surface to trusted internal networks or VPN; do not expose it directly to the internet. 4) Tighten CORS configuration to an explicit allowlist of trusted origins rather than wildcard/permissive settings. 5) Rotate all credentials and API keys stored within Langflow flows, since any prior exposure window may already have leaked a superuser token. 6) Detection: audit access logs for calls to /api/v1/login/auto_login from unexpected source IPs, and review admin-level actions (flow edits, user/API-key creation) for anomalies in the affected window.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-9103?
IBM Langflow's /api/v1/login/auto_login endpoint hands out long-lived superuser bearer tokens to anyone who asks, no credentials required, because the AUTO_LOGIN setting is enabled by default in every OSS deployment from 1.0.0 to 1.10.0. Any network attacker who can reach the instance gets full administrative control over the platform in a single unauthenticated request (CVSS 9.8, AV:N/AC:L/PR:N/UI:N), and permissive CORS settings compound the exposure by letting those tokens leak to untrusted origins in browser-based attacks. This is not a novel AI attack technique — it's a textbook broken-authentication bug (CWE-306) sitting in front of an AI orchestration platform that typically holds embedded LLM API keys, connected data sources, and executable agent flows. There is no EPSS or KEV signal yet since this was just published, but the trivial exploitability and default-on misconfiguration make it a prime target for opportunistic internet scanning. Patch to a fixed IBM Langflow release immediately, or at minimum set AUTO_LOGIN=false and take internet-facing instances off public exposure until patched, then rotate any credentials stored in Langflow flows and lock down CORS to trusted origins.
Is CVE-2026-9103 actively exploited?
No confirmed active exploitation of CVE-2026-9103 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-9103?
1) Upgrade to the IBM-patched Langflow release referenced in the vendor advisory (https://www.ibm.com/support/pages/node/7278926) as soon as it is available. 2) Immediately set AUTO_LOGIN=false in any internet-facing or otherwise untrusted-network deployment — this closes the unauthenticated token issuance path even before patching. 3) Restrict network exposure of the Langflow admin/API surface to trusted internal networks or VPN; do not expose it directly to the internet. 4) Tighten CORS configuration to an explicit allowlist of trusted origins rather than wildcard/permissive settings. 5) Rotate all credentials and API keys stored within Langflow flows, since any prior exposure window may already have leaked a superuser token. 6) Detection: audit access logs for calls to /api/v1/login/auto_login from unexpected source IPs, and review admin-level actions (flow edits, user/API-key creation) for anomalies in the affected window.
What systems are affected by CVE-2026-9103?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, RAG pipelines, LLM orchestration/framework platforms.
What is the CVSS score for CVE-2026-9103?
CVE-2026-9103 has a CVSS v3.1 base score of 9.8 (CRITICAL).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0049 Exploit Public-Facing Application AML.T0081 Modify AI Agent Configuration AML.T0084 Discover AI Agent Configuration AML.T0091.000 Application Access Token Compliance Controls Affected
What are the technical details?
Original Advisory
IBM Langflow OSS 1.0.0 through 1.10.0 could allow a remote attacker to gain unauthorized access due to improper authentication in the /api/v1/login/auto_login endpoint. The endpoint issues long-lived superuser bearer tokens without requiring authentication when the AUTO_LOGIN configuration is enabled (enabled by default), which may allow an unauthenticated network attacker to obtain full administrative access. Additionally, permissive cross-origin resource sharing (CORS) settings may allow tokens to be exposed to unintended origins, increasing the risk of unauthorized access.
Exploitation Scenario
An attacker scans the internet for exposed Langflow instances (default ports, common self-hosted deployment patterns) and sends a single unauthenticated GET/POST to /api/v1/login/auto_login. Because AUTO_LOGIN is on by default, the server responds with a valid, long-lived superuser bearer token with no credential check. The attacker uses that token to authenticate to the admin API, enumerate all configured flows, and extract embedded LLM provider API keys and connected data-source credentials. With superuser access, they modify an existing agent flow to add a code-execution or shell component, achieving remote code execution on the host and pivoting into connected cloud services or internal networks reachable from the Langflow server.
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
Related Vulnerabilities
CVE-2026-10561 10.0 Langflow: auth bypass + unauthenticated RCE (CVSS 10)
Same package: langflow CVE-2026-10134 10.0 Langflow: unauthenticated RCE via tool_code injection
Same package: langflow CVE-2026-33309 9.9 langflow: Path Traversal enables file access
Same package: langflow CVE-2026-55255 9.9 Langflow: IDOR allows cross-user flow execution
Same package: langflow CVE-2026-7873 9.9 Langflow: authenticated RCE enables credential theft
Same package: langflow