CRITICAL: Langflow CVE-2026-9198 Hits CISA KEV as Exploit Code Spreads

Pour one out for anyone who spun up a Langflow instance last quarter to prototype an AI agent, showed it off in a sprint demo, and then never thought about it again. That forgotten container is now a federally recognized emergency.

CISA added CVE-2026-9198 to its Known Exploited Vulnerabilities catalog this week, confirming in an advisory what exploit developers had already been demonstrating in public. The flaw carries a CVSS v3.1 base score of 9.8 with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which is about as bad as the scale gets before you run out of room. An unauthenticated attacker with a network path to a default Langflow deployment can execute arbitrary code on the host. No credentials, no user interaction, no clever social engineering pretext. Just a couple of HTTP requests.

Federal civilian agencies have until August 7 to patch or stop using the product. Everybody else gets whatever deadline their own risk tolerance produces, and given that working proof of concept code is circulating publicly and a Metasploit module is taking shape, the honest answer is today.

What Langflow is, and why that matters here

Langflow is IBM's open source visual builder for LLM applications and agent workflows. You drag components onto a canvas, wire them together, and the platform executes the resulting pipeline. Running user-supplied Python is not an abuse of Langflow. Running user-supplied Python is the entire product. That design reality is worth holding onto, because it explains why this particular class of bug keeps resurfacing in this particular tool and why "just sandbox it" is a harder ask than it sounds.

CVE-2026-9198 is classified as CWE-94, improper control of code generation, and it works by chaining two endpoints that were never supposed to be reachable by a stranger in the same breath. The first is /api/v1/auto_login. In a default configuration it mints a SUPERUSER token for anyone who asks, no authentication required. The endpoint exists for a perfectly reasonable convenience reason, namely that a developer running Langflow on a laptop should not have to log in every thirty seconds. Put that same default container on a cloud VM with a public IP and it becomes a vending machine that dispenses administrative tokens to the internet.

The second endpoint is /api/v1/validate/code. Its job was to check whether a block of Python was syntactically valid, and it did that by feeding the code to exec() and seeing what happened. Validation that executes the thing it is validating is not validation. It is a remote shell with a friendlier name and better error messages.

Chain the two and the exploit is short enough to fit in a tweet. Ask auto_login for a token, present that token to validate/code, include whatever Python you feel like running, and the Langflow process runs it with its own privileges. Affected versions are IBM Langflow OSS 1.0.0 through 1.10.0. The fix landed in 1.10.1 back in July, and it does the obvious correct thing by replacing exec()-based validation with compile-only validation, which is what syntax checking should have been doing since the first commit.

Not Langflow's first trip to the KEV catalog

If this feels familiar, that is because it should. In July, CISA added CVE-2026-0770 to the same catalog, another unauthenticated remote code execution flaw in Langflow rooted in that same validate/code endpoint and the same unsafe exec() call, affecting versions 0.0.31 through 1.7.3. Researchers tracked more than 220 exploitation attempts from 64 unique source addresses beginning in late June. Post-exploitation activity was not subtle or particularly creative, consisting mostly of reconnaissance, credential theft, and bulk collection of environment variables.

That last item is the part people underestimate. When an attacker lands on a Langflow host, the box itself is rarely the prize. The prize is the environment. A working Langflow deployment is where an organization keeps its model provider API keys, its vector database credentials, its connection strings, its retrieval pipeline secrets, and quite often a service account token with more reach into internal data than anyone documented. Dumping the environment of a compromised Langflow container can hand an attacker a running tab on someone else's inference budget plus a map of the internal data the pipeline was built to query. The remote code execution is the door. The credentials are the furniture worth stealing.

Who is exposed and what exploitation looks like

Censys data puts roughly 7,000 Langflow instances reachable on the public internet, with the heaviest concentration in North America. The shape of the typical exposed deployment is depressingly predictable. Somebody needed to demo an agent pipeline, containers are easy, cloud VMs are cheap, the security group got opened to test something from a coffee shop, and the reverse proxy that was going to sit in front of it never got built because the demo went fine without one.

The exploitation signature is straightforward enough to alert on today. Look for a request to /api/v1/auto_login followed within seconds by a request to /api/v1/validate/code from the same source address, especially from addresses that have no business talking to that host at all. On the endpoint side, watch for the Langflow Python interpreter spawning child processes it has no reason to spawn, which in practice means shells, curl, wget, and anything that looks like a package installer. Then watch egress. A Langflow host that suddenly starts making outbound connections to infrastructure it has never contacted before, particularly on odd ports, has almost certainly stopped being yours.

Worth noting that CVE-2026-9198 did not arrive alone. The same batch of KEV additions included Apache Tomcat CVE-2026-34486, a missing encryption issue rated 7.5 that allows a bypass of the EncryptInterceptor component protecting traffic between cluster nodes, patched in April in versions 11.0.21, 10.1.54, and 9.0.117. Exploitation of that one has been attributed to a Chinese-speaking crew running an AI-assisted scanning and exploitation campaign against more than 460 internet-exposed targets, which is its own conversation for another day. The batch also included N-able N-central authentication bypass flaws CVE-2026-18556 and CVE-2026-18577, both rated 8.2 and both actively exploited, with the second CVE existing because the first patch turned out to be incomplete. If you run an RMM stack, that pair deserves your attention every bit as much as the Langflow bug does.

What to actually do about it

Upgrade to Langflow 1.10.1 or later, and be specific about it. A meaningful number of teams will run an update command, watch it report success, and stay vulnerable because their deployment pins an old image tag or because a cached layer served them the same build they already had. Pull the image fresh, confirm the running version from the application itself rather than from the manifest you think you deployed, and restart the service.

If you genuinely cannot patch in the next few hours, cut the attack path instead. Set LANGFLOW_AUTO_LOGIN to false and configure explicit credentials, which alone breaks the token minting half of the chain. Bind the service to 127.0.0.1 and put an authenticating reverse proxy in front of it for any remote access. Block both /api/v1/auto_login and /api/v1/validate/code at the proxy layer for anything coming from an untrusted network. None of that is a substitute for the patch, but all of it buys time.

Then do the uncomfortable part. If your instance was internet-reachable and unpatched at any point since July, treat it as compromised until you can prove otherwise, because the exploit is trivial and the scanning has been continuous. Rotate every API key, model provider token, database credential, and secret that instance could read, and check your model provider billing for usage that nobody on your team can account for. Attackers have been reselling stolen inference capacity for a while now, and a spiking token bill is sometimes the first honest indicator of compromise an organization gets.

The broader lesson here is one that keeps getting relearned the expensive way. AI tooling entered most organizations through developer enthusiasm rather than procurement, which means it landed outside the asset inventory, outside the patch cycle, and outside the vulnerability scanner's scope. Langflow is not uniquely careless. It is simply popular enough to be found, and the same story is waiting to be written about a dozen other agent frameworks running on somebody's forgotten cloud VM right now.

For MSPs, this is the cleanest shadow AI conversation you will get handed all year, so use it. A short discovery engagement that inventories AI tooling across a client environment, checks exposure, and folds those hosts into managed patching sells itself against a live CISA deadline, and the N-central flaws in the same KEV batch give you an equally urgent reason to review the RMM stack while you are already in there.