Zerodayhub

TL;DR — The Langflow RCE tracked as CVE-2026-9198 scores a full 9.8. Two unauthenticated API calls give an attacker arbitrary Python execution on the host. Langflow is an AI agent builder, so that host is usually holding your model provider keys, database credentials and connector tokens. Attackers were hitting it eleven days before IBM said a word. Upgrade to 1.10.1 and assume your secrets are burned.

What Is the Langflow RCE in CVE-2026-9198?

Langflow is an open-source visual builder for AI workflows and agents, maintained by IBM. You wire components together on a canvas — a model here, a retriever there, a tool call at the end — and it runs the resulting flow. It has become a fixture in the AI tooling stack, which is precisely the problem.

The Langflow RCE affects Langflow OSS 1.0.0 through 1.10.0. It is not a memory corruption bug or a clever parser trick. It is two endpoints behaving exactly as written, in a combination nobody sat down and thought about. An unauthenticated attacker chains them and runs whatever Python they like on your server.

What makes this worse than a typical 9.8 is what Langflow is for. An agent-orchestration platform holds the credentials for everything it orchestrates: OpenAI or Anthropic API keys, database connection strings, SaaS connector tokens, and file access for whatever the flows touch. Code execution on a Langflow host is a skeleton key to your whole AI stack.

How the Langflow RCE Works

The exploit is two HTTP requests. That is the entire chain, and it is worth understanding because the pattern generalises well beyond this one product.

Step one: get a token you were never issued. The /api/v1/auto_login endpoint exists to make local development frictionless — it hands you a SUPERUSER session so you are not typing credentials on your own laptop. The failure is that it does not enforce authentication and is not bound to loopback. Anyone who can reach the HTTP API gets a SUPERUSER JWT for the asking.

Step two: ask the server to run your code. With that token, the attacker POSTs JSON containing Python source to /api/v1/validate/code. That endpoint is meant to check whether a custom component compiles — and it does so by passing the source to exec(). The code runs in the Langflow server process, under the service account.

# Conceptual shape of the chain - not a working exploit
POST /api/v1/auto_login        ->  200 OK, SUPERUSER JWT issued to anyone
POST /api/v1/validate/code     ->  body contains Python, evaluated via exec()
                               ->  arbitrary execution as the Langflow service account

Formally this is CWE-94, improper control of code generation. Two design decisions collided: a convenience default that assumed a trusted network, and a validation routine that used exec() where an AST-only parse would have done the job safely. Neither is exotic. Both are the kind of thing that survives code review because each looks reasonable in isolation.

Reading the CVSS Score

There is not much nuance to argue over here. Unlike scores that flatter themselves, this vector earns its 9.8.

Everything on the exploitability side is maximal — network-reachable, low complexity, no privileges, no user interaction — and all three impact metrics are High. The only metric not pinned is S:U, meaning the damage is scored as staying within Langflow’s own security scope. In practice, given the credentials Langflow holds, that boundary is polite fiction.

EPSS sits at 0.019, around the 77th percentile. Note the tension: EPSS is a prediction, and it is predicting fairly modest odds, while CISA has confirmed the thing is being exploited right now. When those two disagree, confirmed beats predicted, every time.

Active Exploitation of the Langflow RCE

The dates on this one deserve a second look. IBM disclosed the vulnerability on 17 July 2026 and shipped the fix the same day — a good, fast response. But KEVIntel telemetry records exploitation attempts beginning 6 July, eleven days earlier. Somebody was using this before the world knew it existed.

The volume since then is substantial: roughly 650 recorded attempts from 244 unique IP addresses across 41 countries. That distribution says commodity scanning rather than targeted operations. Public exploit code is circulating. If you have had an internet-facing Langflow instance on a vulnerable version at any point since early July, treat it as compromised rather than at risk.

One clarification worth making, because reporting has blurred it. Palo Alto’s Unit 42 documented a Chinese-speaking actor using DeepSeek via the Hermes Agent framework to run autonomous attacks. That campaign did probe Langflow — but a different flaw (CVE-2026-33017), and the attempt failed because the target had neither auto_login enabled nor a public flow ID. The agent then pivoted to a different product entirely. It is a striking piece of research, and it is not the story of CVE-2026-9198. The exploitation here looks like ordinary humans with ordinary scanners.

What to hunt for in your logs:

• Any request to /api/v1/auto_login from a non-loopback source address
• Requests to /api/v1/validate/code that you cannot tie to a known developer session
• Outbound connections from the Langflow host to destinations its flows never legitimately call
• Use of model provider API keys from IP addresses outside your normal ranges — often the first visible sign that stolen credentials are being spent

Remediation & Mitigation: Patching Langflow

Upgrade to Langflow 1.10.1 or later. The fix has been available since 17 July 2026. Every release from 1.0.0 to 1.10.0 is affected.

Patching closes the hole but does nothing about what already walked out of it. If your instance was exposed, work the list below in order.

• Patch. 1.10.1 or later, on every instance — including the proof-of-concept someone stood up in a container and forgot about.
• Get it off the internet. Langflow is a development and orchestration tool. It has no business being publicly reachable; put it behind a VPN or an authenticating proxy.
• Rotate every secret it held. Model provider API keys, database credentials, connector tokens, webhook secrets. Assume all of them were readable, because they were.
• Audit downstream. Check the billing and usage logs on your model providers for unexplained spend, and review any system a Langflow flow had credentials for.

The wider point: AI tooling has been adopted far faster than it has been secured, and these platforms concentrate credentials in a way that makes them unusually rewarding targets. A workflow builder holding keys to six services is a higher-value host than most of the servers your patching policy actually covers. Treat the AI stack as production infrastructure, because attackers already do.

Related ZeroDayHub Coverage

We have tracked this pattern before: the earlier Langflow workflow-hijack IDOR, which showed the same platform trusting its own API surface too much; and the N-able N-central authentication bypass, another case of a management platform becoming the fastest route into everything it manages.

Sources & Further Reading

• CISA Known Exploited Vulnerabilities Catalog
• NVD — CVE-2026-9198
• The Hacker News — CISA flags Langflow, Tomcat and N-central flaws
• SentinelOne — Technical breakdown of the endpoint chain
• Indusface — Root cause and disclosure timeline
• KEVIntel — Observed exploitation telemetry
• Unit 42 — Autonomous AI cyberattack campaign