Langflow CVE-2026-9198 — a fifth distinct unauthenticated RCE, chaining a free SUPERUSER token from /auto_login into /validate/code's exec(); added to CISA KEV under active exploitation

View raw markdownEdit on GitHub ↗

TL;DR

CVE-2026-9198 (CVSS 9.8) is a fifth, independently exploitable, unauthenticated RCE in Langflow, distinct from the already-tracked CVE-2026-33017, CVE-2026-27966, CVE-2026-5027, and CVE-2026-0770. The root cause is a two-step chain: Langflow's /api/v1/auto_login endpoint mints a SUPERUSER token for any network caller with no authentication, and the /api/v1/validate/code endpoint then executes attacker-supplied Python via exec() — so an unauthenticated attacker gets a valid superuser token in one request and full code execution in the next. IBM disclosed the flaw 2026-07-02, fixed in Langflow 1.10.1 (versions 1.0.0–1.10.0 affected). CISA added it to the Known Exploited Vulnerabilities catalog on 2026-08-05, citing 650+ exploitation attempts from 244 unique IPs across 41 countries starting 2026-07-06 — meaning active, in-the-wild exploitation began roughly a month before the vendor's own disclosure date, and continued for a full month before the KEV addition forced federal agencies to a 2026-08-07 remediation deadline.

What happened

Langflow — the visual drag-and-drop AI agent/workflow builder this repo already tracks for four other independently-discovered RCE-class bugs (CVE-2026-33017, CVE-2026-27966, CVE-2026-5027, and CVE-2026-0770) — has a fifth, structurally different one.

The bug (CWE-94, Code Injection): 1. /api/v1/auto_login is designed to let a locally-hosted, single-user Langflow instance skip a login screen — but it mints a valid SUPERUSER session token for any network caller, without checking that the request originates locally or that authentication is actually appropriate for the deployment. 2. /api/v1/validate/code — intended for validating a flow-component's Python code before running it — takes that code and passes it straight into exec(), additionally processing decorators, default arguments, and type annotations at function-definition time (meaning even "just parsing" the submitted code can trigger execution side effects).

Chained together: an unauthenticated attacker calls /auto_login to obtain a superuser token, then calls /validate/code with that token and attacker-chosen Python, achieving full remote code execution on the host — commonly with root privileges in default/containerized deployments, the same blast-radius pattern already documented for this repo's other Langflow entries.

This is a distinct root cause from the already-tracked CVE-2026-0770 (which passes an exec_globals parameter directly into exec() on an endpoint that has no authentication step at all) — CVE-2026-9198's novelty is the auth-bypass step (/auto_login handing out a real superuser credential to anyone who asks) layered in front of a separate code-execution primitive. Both land in the same place (root RCE), through different doors.

Disclosure and exploitation timeline: IBM published its security bulletin 2026-07-02, with the fix shipped in Langflow OSS 1.10.1. CISA's KEV entry, added 2026-08-05, cites telemetry from KEVIntel showing 650 exploitation attempts from 244 unique attacker IPs across 41 countries starting 2026-07-06 — four days after IBM's own disclosure but well before the KEV listing, underscoring this repo's standing guidance that AI-framework CVEs move from disclosure to mass exploitation in days, not weeks. The KEV addition set a 2026-08-07 remediation deadline for U.S. federal civilian agencies (Binding Operational Directive 26-04). The same CISA bulletin also flagged unrelated Apache Tomcat (CVE-2026-34486) and N-able N-central (CVE-2026-18556/-18577) flaws — those are out of scope for this advisory.

Am I affected?

# Check your installed Langflow version
pip show langflow 2>/dev/null | grep -i version
# or, for a running instance:
curl -s https://your-langflow-host/api/v1/version

# Confirm whether auto-login is enabled (it is, by default)
grep -i auto_login ~/.langflow/.env 2>/dev/null
echo ${LANGFLOW_AUTO_LOGIN:-"true (default — auto-login is ON)"}

# Test (from an authorized host only) whether /auto_login is reachable unauthenticated
curl -s -o /dev/null -w "%{http_code}\n" https://your-langflow-host/api/v1/auto_login

You're affected if you run Langflow 1.0.0 through 1.10.0 with the instance reachable from any untrusted network (including your office LAN, a shared VPC, or the public internet) and LANGFLOW_AUTO_LOGIN left at its default (true).

If you are affected

  1. Upgrade to Langflow ≥ 1.10.1 immediately — this is under active, high-volume exploitation.
  2. If you cannot upgrade immediately, set LANGFLOW_AUTO_LOGIN=false and put the instance behind authenticated network access (VPN, reverse-proxy auth) as a stopgap — not a substitute for patching.
  3. Treat any pre-patch internet-exposed instance as compromised: rotate every LLM-provider key, cloud credential, and database credential the instance had access to.
  4. Check host-level indicators of compromise (unexpected processes, outbound connections, new cron jobs/scheduled tasks) given the 2026-07-06 exploitation start date — you may have been exploited weeks before the KEV listing made this visible.

→ playbooks/if-your-webapp-was-compromised.md → playbooks/rotating-cloud-credentials.md

Prevention

→ prevention/agent-sandboxing.md → prevention/supply-chain-attack-surface.md - Never expose Langflow directly to the internet. This is now the third actively-exploited, KEV-listed Langflow RCE this repo tracks in under six months (CVE-2026-33017, CVE-2026-55255, and this one) — treat any internet-facing Langflow deployment as a "when," not "if," compromise scenario. - Disable auto-login on any multi-user or network-reachable deployment. LANGFLOW_AUTO_LOGIN exists for local single-user convenience; it is not a safe default for anything else. - Treat any AI-workflow tool that executes user-submitted code (exec(), eval()) as a privileged sandbox boundary, not an ordinary API endpoint — the "AI/data tools shipping unauthenticated network RCE primitives" cluster this repo tracks (Langflow, PraisonAI, Marimo, LiteLLM, Flowise) all share this same root pattern.

Sources