CVE-2026-9198: Langflow's Unauthenticated RCE Chain, and Why It's Worse Than July's Bug

No password, no session cookie, no guessed ID. CVE-2026-9198 gets an attacker to full code execution on a Langflow server using two API calls that require nothing but network access. CISA added it to the Known Exploited Vulnerabilities catalog on August 4, and it lands on a product that already had a KEV entry a month earlier, for a completely different bug.

How the chain actually works

Langflow is an open-source visual builder for AI agent and RAG workflows, the kind of tool a team stands up to let non-engineers wire together prompts, tools, and data sources without writing a full application. That convenience-first design is exactly what makes CVE-2026-9198 so clean to exploit.

The first call hits /api/v1/auto_login. In affected versions, this endpoint hands out a SUPERUSER access token to any caller on the network, no username or password required. It was built for single-user local setups where a login screen felt like pointless friction. The second call sends that token to /api/v1/validate/code, an endpoint meant to let the UI check whether a snippet of Python compiles before saving it. Instead of just parsing the code, it runs it through exec().

Put the two together and an unauthenticated attacker gets arbitrary Python execution as SUPERUSER, which in practice means full control of the host Langflow is running on. IBM’s advisory classifies it under CWE-94, improper control of generation of code, and confirms the affected range as Langflow OSS 1.0.0 through 1.10.0.

Worse than the bug from a month ago

If this sounds familiar, it should. In July, Langflow patched CVE-2026-55255, an insecure direct object reference in the /api/v1/responses endpoint that let an authenticated attacker access another user’s flow by guessing a UUID. We covered that one in detail when it hit the KEV catalog. That bug required a valid session first.

CVE-2026-9198 skips that requirement entirely. There’s no account to compromise and no ID to guess, just two HTTP requests against a default-configured instance. For a team that patched the July bug and considered Langflow handled, this is a reminder that one fixed CVE doesn’t mean the product’s threat model is settled. Two unrelated critical vulnerabilities landing on the same product within a month says more about how the software was designed than about bad luck.

Who’s exposed

Any organization running Langflow OSS 1.0.0 through 1.10.0 with the instance reachable from an untrusted network, which in practice means the public internet in a lot of deployments. Langflow’s target audience skews toward teams building internal AI tooling quickly, and quickly-built internal tools have a habit of ending up exposed without anyone running a formal review first. Shodan-style scanning for exposed AI agent platforms has picked up meaningfully since Langflow’s first KEV listing, and an unauthenticated RCE is the kind of bug that gets weaponized into mass scanning within days of public disclosure.

What to do about it

The patch is straightforward: upgrade to a Langflow release above 1.10.0. But the bulletin’s second recommendation matters just as much, and teams tend to skip it because it’s less mechanical than running an upgrade command.

• Patch first. Upgrade past 1.10.0 immediately on any instance you control.
• Get it off the open internet. Put Langflow behind an authenticating reverse proxy or a VPN, even after patching. auto_login’s design assumption, that anyone who can reach the endpoint should be trusted, is a pattern worth distrusting generally in tools built for local-first use that later get deployed to shared infrastructure.
• Audit what’s stored inside it. Langflow flows commonly hold LLM provider API keys, database credentials, and other secrets needed to run the pipeline. If there’s any chance the instance was reachable before you patched, rotate everything referenced inside its flows, not just the Langflow admin password.
• Check the host, not just the app. Because the exploit grants code execution at the OS level, review for unfamiliar cron jobs, new user accounts, and outbound connections that don’t map to a known integration.

The pattern across AI agent platforms

Langflow landing on the KEV catalog twice in six weeks isn’t really a story about one product. It’s what happens when a category of software, visual AI agent builders, grows fast enough that convenience defaults ship ahead of the security review a general-purpose web application would normally get. The same shape of problem, an endpoint built for a trusted local context that quietly becomes internet-facing, shows up across a lot of the current AI tooling wave. Teams evaluating any AI agent platform for production use should be asking what auto-login, default-open, or “no config needed” behaviors ship out of the box, because those are exactly the defaults that turn into next month’s KEV entry. If your team needs a second set of eyes on an AI tooling stack before it goes anywhere near the internet, our security team runs exactly that kind of review.