CVE-2026-9198

What is Langflow?

Langflow is an open-source visual builder for LLM applications and agent workflows — a drag-and-drop canvas where components (model calls, retrievers, vector stores, tools, custom Python blocks) are wired into a runnable flow and then exposed as an API. IBM acquired it as part of the DataStax acquisition, and it ships as a self-hosted Python service.

The security-relevant property is what a Langflow instance holds. To do its job it stores model-provider API keys, vector-database and SQL credentials, SaaS connector tokens, and whatever secrets the flows themselves need. It also executes user-authored Python by design — arbitrary code execution is a feature of the component model, which means the entire security posture rests on authentication being correct.

Langflow is also frequently stood up for experimentation and left on a public IP with default settings, by teams whose expertise is machine learning rather than infrastructure security.

Overview

CVE-2026-9198 is an unauthenticated remote code execution vulnerability in Langflow OSS, scored CVSS 9.8. It is not a single memory-safety bug but a chain of two design decisions that are individually defensible and jointly catastrophic: an endpoint that hands out superuser tokens to anyone, and an endpoint that executes attacker-supplied Python for anyone holding a token.

Default deployments are vulnerable. No unusual configuration is required — the exposure is the out-of-the-box state.

IBM released Langflow 1.10.1 on the day of disclosure. Public proof-of-concept exploits appeared within about two weeks, and CISA added the CVE to the KEV catalog on 2026-08-04 with a three-day BOD 26-04 deadline.

This is structurally a repeat of CVE-2025-3248, the earlier Langflow validate/code RCE — the same dangerous sink, made reachable again through a different authentication gap.

Affected Versions

The current release line at the time of writing is 1.11.x. Upgrading to 1.10.2 or later is the safer target, since IBM's broader July bulletin covers additional API authorization defects beyond this CVE.

Containerized deployments must be redeployed from the patched image — restarting a container built on a vulnerable version changes nothing.

Technical Details

The chain has two links.

Link one — GET /api/v1/auto_login issues a SUPERUSER token to anyone. This endpoint exists as a local-development convenience so a developer running Langflow on their laptop is not prompted to log in. The problem is that it is not bound to loopback and enforces no authentication of its own. Any client that can reach the service over the network can call it and receive a valid JWT with SUPERUSER privileges.

Link two — POST /api/v1/validate/code passes its body to exec(). This endpoint accepts Python source and executes it server-side as part of validating custom component code. That is intentional: Langflow's component model is built on running user Python. The endpoint trusts the caller's bearer token — the token that link one just handed out for free.

Combined: two HTTP requests take an attacker from unauthenticated network reachability to arbitrary Python execution as the Langflow service account, with everything that account can read — API keys, database credentials, connector tokens — immediately in reach.

Attack characteristics. Unauthenticated, no user interaction, network attack vector, no special network position, no prerequisite access. Low complexity and highly reliable — there is no memory corruption, race, or heap grooming involved, just two API calls. Trivially scriptable for mass scanning, which is what the public PoCs do.

Some vulnerability trackers assign separate identifiers to the two halves of the chain and treat CVE-2026-9198 as the combined issue; that decomposition appears in secondary reporting and has not been confirmed against IBM's own bulletin.

Discovery

Disclosed by IBM, Langflow's current owner. Field Effect cites an initial IBM disclosure date of 2026-07-02, with the CVE published and 1.10.1 shipped on 2026-07-17. No individual researcher credit has been published.

This was not a zero-day — the patch was available on day one. Exploitation followed the public availability of proof-of-concept code, in the familiar pattern where disclosure of an easily-reproduced flaw is itself the starting gun.

Exploitation Context

Public PoCs, including weaponized versions, circulated in late July 2026. CISA confirmed exploitation and added the CVE on 2026-08-04, alongside the Apache Tomcat and N-able N-central entries from the same batch, with a 2026-08-07 deadline.

No threat actor attribution has been published, and no exposure counts (Shodan, Censys, Shadowserver) have been released for this CVE. Some commentary has linked Langflow exploitation to AI-assisted autonomous scanning campaigns active during the same period; that connection is not established by any source that names this CVE directly, and should be treated as speculation.

The impact profile is what makes this worth prioritizing above its raw CVSS. A compromised Langflow instance is rarely valuable for its own compute. It is valuable for the credential set it holds — model-provider keys that can be resold or abused for cryptomining-equivalent LLM billing fraud, plus database and SaaS credentials that lead somewhere else on the network. Treat a compromise as a credential-theft incident first and a host-compromise incident second.

Remediation

1. Upgrade to Langflow 1.10.1 at minimum; prefer 1.10.2 or the current 1.11.x to also close the additional API authorization issues in IBM's broader July bulletin.
2. Redeploy containers from the patched image. A restart of an existing container does not apply the fix.
3. Verify the fix directly. Confirm that an unauthenticated GET /api/v1/auto_login no longer returns a usable token. This is a two-second check and is more reliable than trusting a version string.
4. Get Langflow off the public internet. Place it behind an authenticating reverse proxy or VPN. Given that arbitrary code execution is an intended feature of the platform, direct internet exposure is a poor posture even fully patched.
5. Rotate every secret the instance held or could reach — model-provider API keys, vector store and database credentials, connector tokens, and any credentials referenced inside flows. If the instance was exposed before patching, assume these are gone.
6. Hunt for post-exploitation persistence. Check for new cron entries, added SSH authorized keys, unexpected child processes of the Langflow service, modified flow definitions, and anomalous outbound network connections.
7. Review access logs for requests to /api/v1/auto_login and /api/v1/validate/code, particularly from unfamiliar source addresses, back to at least mid-July 2026.