Langflow's Auto-Login Endpoint Was Handing Out Admin Tokens — CVE-2026-9198 Has Been Under Attack Since Before It Had a CVE
A two-request chain turns any Langflow AI-agent server into root: one endpoint mints a superuser token to anyone who asks, the next runs whatever Python you hand it. KEVIntel's sensors caught scanning for it eleven days before the CVE was even published.
Langflow is an open-source visual builder for LLM-powered agents and workflows — the kind of tool a team stands up to wire together model calls, retrieval steps, tool invocations and database lookups, then exposes as an internal API. On August 4, 2026, CISA added CVE-2026-9198 to its Known Exploited Vulnerabilities catalog: an unauthenticated, two-request chain that hands an attacker full remote code execution on any default Langflow deployment.
The unusual part isn't the bug — code-execution flaws in AI agent platforms have become routine this year. It's the timeline. Sensor telemetry shows exploitation attempts starting July 6, 2026 — eleven days before IBM even published the CVE.
The chain: two requests, zero credentials
IBM's own advisory describes it as one flaw, but it's really two design decisions colliding. /api/v1/auto_login exists to streamline local development — it mints a SUPERUSER session token automatically. In affected versions that behavior isn't gated by network origin, single-user mode, or an explicit opt-in flag: any caller who can reach the HTTP listener gets a fully privileged token. /api/v1/validate/code exists to let the UI check component code before running it — it hands attacker-supplied Python straight to exec(). Chain the two and an anonymous network caller gets a superuser token, then uses it to execute arbitrary code.
CVE-2026-9198 — from anonymous request to code execution
- Attacker, no credentials — Any network caller that can reach the Langflow HTTP listener
- POST /api/v1/auto_login — Endpoint built for local-dev convenience
- AUTO_LOGIN enabled? — Default-on for Langflow < 1.5; must be explicitly set on newer builds
- SUPERUSER token issued — No credentials, no origin check, no local-only binding
- POST /api/v1/validate/code + token — Endpoint's job is to 'validate' submitted Python
- exec() runs attacker Python — Full RCE as the Langflow process — CVSS 9.8, C:H/I:H/A:H
- No token / request blocked — AUTO_LOGIN disabled or bound to loopback — chain breaks here
What the sensors actually recorded
KEVIntel — which correlates CISA, vendor and community telemetry into exploitation timelines — puts numbers on this one. As of today, its record for CVE-2026-9198 shows:
- First sensor sighting: July 6, 2026 — 11 days before the CVE was published
- 775 exploitation attempts logged across 24 sensors
- 302 unique attacker IP addresses, spanning 46 countries
- Public PoC code: July 29, 2026 · Nuclei scanner template: July 29, 2026
- Added to CISA KEV: August 4, 2026, 16:45 UTC · federal deadline August 7
- Activity is ongoing — last observed attempt: today, August 23, 2026
Exploitation telemetry as of 2026-08-23live record →
Langflow's fourth KEV-listed critical in under two months
CVE-2026-9198 isn't Langflow's first brush with CISA's list this year — it's the fourth distinct unauthenticated-RCE-class bug we've tracked on this platform since March, each independently exploited and each involving a different endpoint that trusted input it shouldn't have.
| CVE | Weakness | Endpoint | EPSS | KEV'd |
|---|---|---|---|---|
| CVE-2025-3248 | CWE-94 code injection | /api/v1/validate/code | ~100% | Yes — Metasploit-weaponized, used for the Flodrix botnet |
| CVE-2026-33017 | CWE-94 / CWE-306 missing auth | /api/v1/build_public_tmp/{flow_id}/flow | 96.2% (99.9th pctile) | Yes — weaponized within ~20 hours, Monero mining + cloud-key theft |
| CVE-2026-55255 | CWE-639 IDOR | authenticated /api/v1/responses | 29.1% | Yes — 3-day KEV deadline despite comparatively low CVSS (8.4) |
| CVE-2026-9198 | CWE-94 code injection | /api/v1/auto_login + /api/v1/validate/code | 18.8% (97.1th pctile) | Yes — attempts recorded before the CVE existed |
Same week, two other KEV adds — don't conflate the stories
CVE-2026-9198 landed on KEV alongside two N-able N-central authentication-bypass flaws (CVE-2026-18556 and its incomplete-patch follow-up CVE-2026-18577 — we covered that chain in depth already) and an Apache Tomcat encryption bypass, CVE-2026-34486. The Tomcat bug matters here for a different reason: it's been tied by Palo Alto's Unit 42 to a Chinese-speaking actor running autonomous exploitation via a DeepSeek-powered agent framework.
What's actually confirmed about CVE-2026-9198 vs. a story often blended into it
- Unauthenticated auto_login → validate/code chain, CVSS 9.8
- Sensor hits since July 6, 2026: 775 attempts / 302 IPs / 46 countries
- Public PoC + Nuclei template by July 29
- KEV added August 4; CISA discloses no exploitation-method detail
- Unit 42 documented a DeepSeek-driven agent (the 'Hermes Agent' framework) attacking a *different* Langflow bug, CVE-2026-33017
- That attempt failed on the target (no auto_login, no public flow ID) — the agent then researched and pivoted to n8n instead
- Real, well-sourced story — it just isn't CVE-2026-9198
Why this class of target keeps producing critical bugs
Langflow instances aren't just web apps — they're typically wired to whatever the workflows they run need: model-provider API keys, vector database credentials, relational database connection strings, cloud access tokens. A compromised Langflow host doesn't hand an attacker a defaced webpage; it hands them the credential set for every system its flows touch. That's the practical reason four unauthenticated-RCE-class Langflow CVEs in under a year is a bigger deal than the CVSS scores alone suggest — and why 'rotate every credential the instance had access to' belongs in the remediation list, not just 'apply the patch.'
Fix it
- Upgrade to Langflow OSS 1.10.1 or later — redeploy the container image rather than patching in place; older builds can silently persist the vulnerable code path.
- Explicitly set LANGFLOW_AUTO_LOGIN=false unless you have a specific, isolated reason not to.
- Never expose the Langflow API directly to the internet — put it behind an authenticating reverse proxy or VPN.
- Rotate every credential the instance had access to — model-provider keys, DB connection strings, cloud tokens — on any host that was internet-reachable before patching.
- Audit for prior compromise: unfamiliar cron entries, new SSH authorized_keys, unexpected outbound connections.