Censys counted roughly 7,000 internet-facing Langflow instances in March. On July 17, IBM shipped a same-day fix for CVE-2026-9198, a CVSS 9.8 bug that lets an unauthenticated caller mint a superuser token and hand it arbitrary Python to run. CISA added it to the Known Exploited Vulnerabilities catalog on August 4 with a federal remediation deadline of August 7. That deadline has already passed. Nobody has published a fresh count of how many of those 7,000 boxes got patched in three weeks, and the honest answer, based on how the last Langflow RCE played out, is not many.
If you do not run Langflow, Flowise, LangGraph, or any self-hosted AI agent-orchestration platform, this specific CVE is not yours, and you can skip to the last section. If you do, or if you are not certain whether someone on your team spun one up during a hackathon and never told anyone, keep reading. The vulnerability is the smaller story here. The bigger one is that AI agent infrastructure is showing up on your attack surface faster than your asset inventory can track it, and CVE-2026-9198 is just the clearest recent proof.
The chain: two endpoints, zero authentication, full RCE
Langflow is an open-source visual builder for chaining LLM calls, tools, and agents into a workflow, the kind of thing a data science team stands up to prototype an internal copilot. CVE-2026-9198 is a CWE-94 code injection tracked against every Langflow OSS release from 1.0.0 through 1.10.0, fixed in 1.10.1. The chain is short enough to explain in two lines:
/api/v1/auto_loginissues a superuser bearer token to any caller, authenticated or not, on a default deployment./api/v1/validate/codeaccepts a bearer token and a code payload, then executes that payload with the privileges the token carries.
Call the first endpoint, get a superuser token back. Hand that token to the second endpoint with a Python payload. The platform runs it as the application user, no credentials checked at any step, according to IBM's own advisory. That is full remote code execution against a server most teams deployed to move fast on an AI proof of concept, not to expose an unauthenticated code-execution API to the internet.
This is Langflow's second unauthenticated RCE since June
CVE-2026-9198 is not an isolated slip. Langflow disclosed CVE-2026-5027, a separate unauthenticated RCE, in June, and that one also saw active exploitation before most operators patched. Two critical, pre-auth, remotely exploitable bugs in the same product inside three months is a pattern, not a fluke. KEVIntel's exploitation telemetry, reported by The Hacker News, recorded the first attack attempts on July 6, eleven days before IBM's public disclosure and patch, from 244 distinct attacker IPs across 41 countries by early August. Someone was scanning for this before the vendor told the world it existed.
The lesson is not "stop using Langflow." The lesson is that the current generation of AI agent-orchestration platforms was built by teams optimizing for developer velocity, and authentication on internal-facing admin and execution endpoints was treated as a deployment detail instead of a default. That is a young-product problem, and it is going to keep producing pre-auth RCEs in this category until the tooling matures. Plan your exposure management around that assumption instead of around any single patch.
Why your asset inventory misses these servers
A firewall rule review or a CMDB export rarely surfaces a Langflow instance, because nobody submitted a change ticket to stand it up. An engineer pulled the Docker image, ran it on a box with a public IP because that was the fastest way to demo something to a stakeholder, and it is still running eight months later. The same pattern shows up with MCP servers, the integration layer that lets AI coding agents pull data from tools like Sentry, Jira, and internal wikis. Cloud Security Alliance researchers documented how an MCP server bridging Sentry to coding agents such as Claude Code, Cursor, and Codex can be turned against the developer it serves: an attacker posts a crafted error event to a public Sentry DSN, the agent retrieves it through MCP as a routine diagnostic, and treats the attacker's embedded instructions as trusted guidance. Testing across those agents found an 85 percent exploitation success rate, and a scan of exposed Sentry DSNs found at least 2,388 organizations with an injectable path.
The common thread with Langflow is not the specific bug. It is that both categories of server were provisioned outside the normal change process, run with implicit trust in whatever data reaches them, and never made it onto a list anyone reviews. Identity and access management, endpoint detection, and network monitoring all stayed quiet in the Cloud Security Alliance research, because every step the agent took was, technically, authorized. Your controls cannot flag a server they do not know exists.
Hunting your own exposure before a scanner finds it for you
You do not need to wait for a vendor bulletin to know if you are carrying this risk. Start with what is reachable from the outside, since that is exactly what the attackers scanning for CVE-2026-9198 are doing. A quick fingerprint against a candidate host, run against your own infrastructure only, tells you whether Langflow is listening and roughly which version:
#!/usr/bin/env bash
# Fingerprint a host you own for an exposed Langflow instance.
# Read-only: checks the health endpoint and version banner, does not
# call auto_login or validate/code.
HOST="$1"
PORT="${2:-7860}"
echo "[*] Checking ${HOST}:${PORT} for Langflow..."
curl -s -o /dev/null -w "health: %{http_code}\n" \
"http://${HOST}:${PORT}/health"
curl -s "http://${HOST}:${PORT}/api/v1/version" \
| python3 -c "import sys,json; d=json.load(sys.stdin); print('version:', d.get('version','unknown'))" \
2>/dev/null || echo "version: endpoint not present or not Langflow"
Running that host by host against every IP range your org owns is how attackers already found the roughly 7,000 instances Censys catalogued. We run the same class of check at scale with our open-source tool, scopecheck: point it at a domain or CIDR list and it resolves live hosts, fingerprints the stack behind each one, and flags anything that looks like a self-hosted AI platform, admin console, or other service that should not be internet-facing. Pair it with portdiff to diff your exposed surface week over week, the same way you would want to know the moment a new RDP listener or database port shows up.
If you already run Langflow behind a proxy or a WAF that logs requests, you can hunt for exploitation attempts on the exploit chain itself instead of just the version banner. A request to /api/v1/auto_login immediately followed by a POST to /api/v1/validate/code from the same source IP, especially one you do not recognize as an internal build agent, is the two-step signature of this specific chain:
# Pull matching request pairs from an nginx-style access log
awk '{print $1, $7}' /var/log/nginx/langflow-access.log \
| grep -E "/api/v1/(auto_login|validate/code)" \
| sort | uniq -c | sort -rn | head -20
A source IP that hits both paths within a few seconds of each other, particularly one outside your office or VPN egress ranges, is worth pulling the full request body for. That log line is also the fastest way to tell whether the instance you just found has already been touched, which changes your response from "patch and move on" to "patch, rotate, and start an investigation."
What to do once you find a live instance
- Upgrade to Langflow 1.10.1 or later immediately; do not wait for a maintenance window on a server that is reachable from the internet.
- Put it behind a VPN or an identity-aware proxy so
/api/v1/auto_loginis never reachable from an untrusted network, patched or not. - Rotate every credential and API key the instance had access to, since a prior compromise would not necessarily leave an obvious trace.
- If the box also runs an MCP integration to Sentry, GitHub, or another external service, audit that integration for the same untrusted-input problem the Cloud Security Alliance describes, not just the Langflow CVE.
The organizations that get burned by the next Langflow-class bug are not the ones running an outdated version. They are the ones who cannot answer, in under five minutes, whether they are running it at all. That is an inventory gap, and it is fixable this quarter with a scan, not a six-month platform migration.
Put every AI agent server on your exposure map, not just the ones you remember deploying
Patch the Langflow instance if you have one. Then go find the ones nobody remembers deploying. Run a full external scan of your own IP space for Langflow, Flowise, LangGraph, and any bare MCP server listening on a public port, add whatever you find to the same asset inventory that already tracks your firewalls and domain controllers, and put it on a recurring scan instead of a one-time cleanup. The tooling teams are shipping to build AI agents moves faster than the change-management process most companies use to track what is exposed, and that gap is where the next unauthenticated RCE will land.
Want to try our open-source security tools?
We build open-source tools that automate the tedious parts of exposure management, including scopecheck for external attack surface mapping and portdiff for tracking what changes on it. Check them out on GitHub, or book a session to talk through hunting shadow AI infrastructure in your environment.