Most of the CVEs we cover here start with a researcher finding a flaw before anyone exploits it. CVE-2026-9198 didn't stay in that category for long. According to IBM's own security bulletin and CISA's 4 August advisory, a critical flaw in Langflow OSS - versions 1.0.0 through 1.10.0 - lets an unauthenticated attacker on the network go from zero access to a superuser shell on the host, using nothing more than two ordinary API calls. IBM rated it CVSS 9.8 and patched it the day it went public. Weeks later, CISA confirmed it was being actively exploited anyway.
Two endpoints, and neither one should have trusted the other
The chain itself is almost insultingly simple once you see it written down. Langflow's /api/v1/auto_login endpoint, designed to smooth over local development, mints a valid SUPERUSER authentication token for any caller who asks - no username, no password, no prior session. An attacker takes that token straight to /api/v1/validate/code, an endpoint built to let users test custom Python components inside their agent workflows, and hands it a payload instead of a component. The endpoint runs it through Python's exec() as an administrator. Two requests, no authentication, full remote code execution. There isn't a third step because the design didn't need attackers to find one.
Langflow existed to make it easy for non-specialist teams to wire together AI agents - drag a retrieval step here, a tool call there, an LLM prompt in between - without writing a service from scratch. That's exactly why the auto-login shortcut existed in the first place: it was built for a trusted local loop, then shipped in a product routinely deployed on a shared network or the open internet, where "trusted caller" isn't a category that exists.
A same-day patch and a three-week gap aren't a contradiction
IBM's response was about as fast as vendor response gets - disclosure and a fixed release on the same day, 17 July, well ahead of any pressure to act. The problem CISA's KEV addition points at isn't IBM's patch timeline; it's the population of Langflow instances that were still running 1.10.0 or earlier three weeks later, reachable from the internet, with nobody watching for the update. We've flagged this exact gap before - over half of internet-facing N-central servers were still unpatched days after a KEV addition, and JetBrains' TeamCity flaw sat unexploited by the vendor's own account for nine days before CISA found otherwise. A same-day fix only closes the hole for people who apply it same-day. Everyone else is on the same clock as if no patch existed, and attackers scanning for exposed Langflow instances don't care how fast IBM moved.
Why this one belongs in the AI governance conversation, not just the patching one
What makes CVE-2026-9198 worth a second look isn't the exploit chain - unauthenticated-token-plus-code-execution is a familiar shape. It's what sits behind a Langflow instance once you're root on it: the credentials, API keys and tool connections that the AI agents built on top of it were configured to use. We've written about the identity sprawl question this creates for non-human identities tied to AI agents and the governance gap around integration points like MCP that agent platforms increasingly depend on. A compromised agent-orchestration server isn't just a compromised host - it's a compromised set of credentials for whatever that server's agents were trusted to touch, which in a production deployment can mean production data, ticketing systems, cloud accounts or customer records.
- Check whether any Langflow OSS instance in your estate - including ones spun up by individual teams outside a formal platform inventory - is running 1.10.0 or earlier, and upgrade past the fixed release immediately.
- If you can't upgrade today, take the instance off direct internet exposure and put it behind an authenticating reverse proxy or VPN; that alone closes the unauthenticated attack path.
- Audit what credentials and tool connections are configured on any Langflow instance you run - a compromised orchestration server exposes everything its agents were trusted to reach, not just the host itself.
- Add "who owns patching this" to your AI agent tooling inventory now, before the next flaw in this category, since low-code AI platforms are exactly the kind of tool individual teams adopt outside normal patch governance.
The pattern here isn't new - a same-day fix, a lagging patch cycle, a KEV addition weeks later - but the target is a reminder that AI agent tooling has quietly become production infrastructure faster than most patch management programmes have caught up with it. If you need help getting AI agent platforms and their credentials properly inventoried and patched, email sales@halfteck.com.