Langflow's Auto-Login Gave Attackers a SUPERUSER Token With Zero Credentials: CVE-2026-9198 Patch Guide

Langflow’s development convenience feature was quietly handing out the keys to the kingdom: CVE-2026-9198 (CVSS 9.8, critical) is an unauthenticated remote-code-execution chain in IBM Langflow OSS that needed zero credentials — one request to get a SUPERUSER token, a second to execute arbitrary Python on the host. CISA added it to its Known Exploited Vulnerabilities catalog on August 4, 2026, and threat sensors recorded 775 exploitation attempts from 302 IPs across 46 countries. This week’s vulnerability roundups still list Langflow as an actively targeted AI platform. If you self-host Langflow — especially alongside n8n — upgrade to 1.10.1 and explicitly set LANGFLOW_AUTO_LOGIN=false now. This post explains the chain, whether you’re exposed, and how to patch.

The chain: two requests, zero credentials

IBM’s advisory describes one flaw, but it’s really two design decisions colliding:

1. POST /api/v1/auto_login exists to streamline local development — it mints a SUPERUSER session token automatically. In affected versions this wasn’t gated by network origin, single-user mode, or any explicit opt-in: any caller that could reach the HTTP listener got a fully privileged token. (AUTO_LOGIN is default-on in Langflow below 1.5 and must be explicitly enabled on newer builds.)
2. POST /api/v1/validate/code exists so the UI can “validate” component Python before running it — it passes the submitted code to Python’s exec() with no sandbox.

Chain the two and an anonymous network caller gets a superuser token, then uses it to execute arbitrary code as the Langflow process — frequently root. The public exploit PoCs wrap the payload in a function default argument (evaluated at definition time) so the output comes back in the response — but the defensive takeaway is simpler: if your instance was internet-reachable with auto-login on, assume it was exploitable by anyone.

The attacks started before the CVE existed

The most striking part of this story is the timeline. Sensor telemetry shows exploitation attempts starting July 6, 2026 — eleven days before IBM even published the CVE:

• July 6, 2026: first sensor sighting of exploitation attempts
• July 29, 2026: public proof-of-concept repositories and a Nuclei scanning template appear
• August 4, 2026, 16:45 UTC: CISA adds CVE-2026-9198 to its KEV catalog (federal patch deadline: August 7)
• Ongoing: this week’s roundups (malware.news, Cyble) note sensors are still catching attempts against Langflow, alongside renewed interest in an older code-injection flaw (CVE-2025-3248)

Langflow instances are rich targets: the flows they run are typically wired to model-provider API keys, vector-database credentials, relational database connection strings, and cloud access tokens. A compromised Langflow host doesn’t hand an attacker a defaced page — it hands them the credential set for every system its flows touch. That’s why this ranks as Langflow’s fourth distinct unauthenticated-RCE-class bug to land on CISA’s KEV list since March — and why the remediation below includes credential rotation, not just a patch.

Which versions are affected

CVSS 9.8 — attack vector: network, complexity: low, privileges: none, user interaction: none. (Don’t confuse this with the other Langflow CVE published the same day, CVE-2026-105697, a CVSS 9.9 MCP stdio command-injection we covered on October 7 — this one needs no account and no MCP server at all.)

Are you exposed? A 60-second check

1. Which version are you on? pip show langflow or check the Docker image tag. Anything below 1.10.1 is vulnerable.
2. Is LANGFLOW_AUTO_LOGIN on? Check your environment or compose file. It must be explicitly false in anything that isn’t an isolated local dev box — this is the switch the whole chain pivots on.
3. Is the Langflow HTTP listener reachable from the internet? Default port is 7860. Check your reverse proxy, security groups, or probe it from outside your network. If it was ever reachable with auto-login on, treat it as compromised until proven otherwise.
4. What did it have access to? List every API key, DB connection string, and cloud token your flows use — the rotation list starts there.

Warning: the fix is the upgrade, but the upgrade is not the whole fix. If the instance was internet-exposed while vulnerable, patching doesn’t undo what an attacker may have already done. Rotate first, audit second.

How to patch

Prerequisites: back up your Langflow data (flows, credentials, the database or ~/.langflow directory) before upgrading.

Step 1 — Upgrade to 1.10.1 or later

pip install --upgrade "langflow>=1.10.1"

Docker users — pull and recreate the container (your data volume holds flows and the database):

docker pull langflowai/langflow:latest
# recreate the container against the new image

Note: don’t patch the running code in place — redeploy the container image so the vulnerable code path is fully gone.

Step 2 — Explicitly disable auto-login everywhere except isolated local dev

export LANGFLOW_AUTO_LOGIN=false

or in your Docker compose / .env:

LANGFLOW_AUTO_LOGIN=false

Then restart the container.

Step 3 — Never expose Langflow directly to the internet

Put it behind an authenticating reverse proxy (Authelia, oauth2-proxy, Cloudflare Access) or a VPN. Port 7860 should never be publicly routable on an agent platform wired to your API keys.

Step 4 — Rotate every credential the instance could reach

This is the step most teams skip. Rotate model-provider keys (OpenAI, Anthropic, etc.), vector-DB credentials, database connection strings, and any cloud tokens the flows touched. Revoke-and-regenerate, don’t just edit.

Step 5 — Audit the host for prior compromise

• Unfamiliar cron entries or new SSH authorized_keys
• Unexpected outbound connections (reverse shells phone home)
• New superuser accounts inside Langflow itself
• Check logs around any internet-exposed window for POST /api/v1/auto_login from non-local IPs

Why n8n builders should care

Many self-hosted n8n builders run Langflow on the same box or VLAN — prototyping flows in Langflow, orchestrating them in n8n. That proximity turns this from “Langflow’s problem” into an n8n-host risk: an attacker landing on Langflow can pivot to n8n credentials, shared databases, and mounted volumes. If you run both, audit both this week — and apply the same auto-login-off / no-direct-exposure rule you (hopefully) already apply to n8n’s basic auth.

FAQ

Is CVE-2026-9198 different from the other Langflow CVEs this month?

Yes. CVE-2026-105697 (CVSS 9.9, October 5) is a command-injection in MCP stdio server handling. CVE-2026-9198 is older (July, CISA KEV’d in August) — the auto_login → validate/code chain, CVSS 9.8, and the one still showing up in active exploitation telemetry. Patch both if you’re behind.

Does the attack require an account?

No. That’s the point of this CVE: the auto_login endpoint minted a SUPERUSER token for an unauthenticated caller, and validate/code executed their Python. Zero credentials, two requests.

Is there a public exploit?

Yes — public PoCs and a Nuclei scanning template have existed since July 29, 2026. Sensor data shows mass scanning continues, consistent with commodity scanners rather than targeted campaigns. The exploit path is trivial, so unpatched instances are being found automatically.

What if I only ever ran Langflow on localhost?

If the HTTP listener was bound to loopback only (127.0.0.1) and never exposed, you were not remotely exploitable. Still upgrade — and set LANGFLOW_AUTO_LOGIN=false so a future misconfiguration doesn’t reopen the hole.

Images: Pexels