RECONINTEL
◄ ALL POSTS
JULY 21, 2026CVSS 9.8 · CRITICAL · UNAUTHENTICATED CHAIN7 MIN READ

Langflow RCE Chain (CVE-2026-9198): auto_login Auth Bypass Turns validate/code Into Unauthenticated Code Execution

In July 2026, IBM published a wave of Langflow OSS vulnerabilities that includes several authenticated remote code execution flaws — and, more importantly, the unauthenticated flaws that make them reachable. IBM assigned CVE-2026-9198 (CVSS 9.8) to a specific chain: an unauthenticated caller hits /api/v1/auto_login to mint a superuser token, then hits /api/v1/validate/code to run arbitrary Python via exec() — full RCE on a default Langflow deployment. Two other unauthenticated flaws in the same wave, CVE-2026-9103 (the auth bypass itself) and CVE-2026-8505 (a webhook bypass), widen the front door further. It is the same shape as CVE-2026-33017 — the Langflow flaw CISA added to its Known Exploited Vulnerabilities catalog after attackers used it to drop cryptominers on internet-exposed AI servers.

The Pattern: Authentication as a Containment Boundary

Langflow is an open-source visual builder for AI agents and workflows. Its core function is to let users assemble and run Python-backed components — which means the server executes user-defined logic by design. The recurring security problem is not that Langflow runs code; it is that Langflow has repeatedly treated authentication, input validation, and feature flags as containment boundaries for code-execution surfaces that were never sandboxed. When one of those routing controls fails, the result is arbitrary code execution as the Langflow server process. The July 2026 wave is a clean illustration: several distinct execution sinks, and multiple default-on flaws that let an unauthenticated attacker reach them.

The Keystone: CVE-2026-9198 (Officially Assigned Unauthenticated Chain)

  • CVSS: 9.8 Critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) — no authentication required
  • CHAIN: /api/v1/auto_login mints a superuser token to any network caller → /api/v1/validate/code executes user code via exec() → full RCE on default deployments
  • AFFECTED: Langflow OSS 1.0.0 through 1.10.0
  • STATUS: IBM CNA record, published July 17, 2026 (NVD analysis in progress)
  • ADVISORY: NVD: CVE-2026-9198

This matters because the chain is not an inference drawn from separate advisories — IBM assigned it its own CVE. The two halves also exist as standalone records: CVE-2026-9103 (CVSS 9.8) documents the auto_login endpoint issuing long-lived superuser bearer tokens with no authentication when AUTO_LOGIN is enabled — the default — with permissive CORS potentially exposing those tokens to unintended origins (one wrinkle for anyone cross-referencing records: the CVE-2026-9103 entry cites the path as /api/v1/login/auto_login, while the CVE-2026-9198 chain record and Langflow's own advisory use /api/v1/auto_login); CVE-2026-8481 (CVSS 9.9) documents validate/code running user-supplied Python through exec() with no sandbox. CVE-2026-9198 is the composition of the two, established by the vendor.

A Second Front Door: CVE-2026-8505 (Webhook Auth Bypass)

CVE-2026-8505 (CVSS 9.8, unauthenticated) is an independent path to flow execution. Langflow's webhook authentication logic incorrectly bypasses API key validation when WEBHOOK_AUTH_ENABLE is set to False — which IBM's advisory calls the default. Langflow's source tells a more nuanced story: the setting shipped as False only through v1.9.0 and flipped to True from v1.9.1 onward, so across most of the affected range it was not the default. Either way, verify your own deployment rather than trusting the advisory's blanket claim. A remote attacker who knows a flow's UUID can trigger a disabled-auth webhook as if they were the owner, potentially leading to RCE. Like CVE-2026-33017 before it, exploitation hinges on obtaining a flow UUID; unlike the authenticated RCEs, it needs no login at all.

The Sinks: Authenticated RCEs the Bypass De-Gates

Beyond the officially chained validate/code path, the same wave includes four more code-execution flaws, each rated as requiring an authenticated, low-privilege user (PR:L). Two of them (CVE-2026-8476 and CVE-2026-9135) carry a Scope: Changed metric (S:C), meaning the impact crosses a security-authority boundary rather than staying confined to the vulnerable component:

  • CVE-2026-8476: 9.9 (S:C) — the AsyncDiskCache class deserializes cached objects with pickle.loads() without validation. Prerequisite: a usable path to influence data later read from the disk cache (workflow inputs, custom components, the API, or file-system access).
  • CVE-2026-9135: 9.9 (S:C) — the Policies component's ToolGuard integration bypasses allow_custom_components=false, because validation inspects only the main component source, not the dynamic CodeInput fields where ToolGuard code is stored. Prerequisite: flow-creation ability plus later invocation of the guarded tool. (Its record is internally inconsistent on the upper bound — the structured range says through 1.10.0, the description says up to 1.9.2 / commit 94981c4.)
  • CVE-2026-14499: 8.8 — command injection in the Python Interpreter component via improper input validation. Prerequisite: the Python Interpreter component reachable through a flow.
  • CVE-2026-7755: 8.8 — RCE via incomplete validation enforcement on MCP server configuration files. Prerequisite: access to the MCP server configuration path.

How strong is the chaining claim? For the validate/code path, IBM has done the work: CVE-2026-9198 is the assigned, vendor-confirmed unauthenticated chain. The four flaws above are separate two-stage possibilities of the form auth bypass → one authenticated primitive. The auth bypass removes their authentication prerequisite, but each still carries additional prerequisites (cache influence, flow creation, component reachability) and none was reproduced end-to-end for this analysis. Treat them as advisory-derived alternative paths, not confirmed exploits — the architectural point is that on a default deployment, "authenticated-only" is doing far less work than it appears to.

Why This Keeps Happening: The validate/code Timeline

CVE-2026-8481 is not the first time /api/v1/validate/code has been a remote code execution sink. The endpoint's history is the clearest evidence of the pattern — for more than a year Langflow patched the path to Python execution rather than the execution capability itself, until the 1.10.1 fix finally removed execution from the validation endpoint:

  • • CVE-2025-3248 (April 2025, CVSS 9.8) — /api/v1/validate/code was reachable without authentication in versions prior to 1.3.0. A remote unauthenticated attacker could send crafted requests to execute arbitrary code. The fix added an authentication requirement. This one is also CISA KEV-listed (added May 2025).
  • • CVE-2026-33017 (March 2026, CVSS 9.8) — a different unauthenticated endpoint, /api/v1/build_public_tmp/{flow_id}/flow, reached an unsandboxed execution sink via attacker-supplied flow data in versions prior to 1.9.0. This one was actively exploited and added to CISA KEV; threat research tied it to cryptominer deployment on exposed Langflow servers. Exploitation required knowing or creating a public-flow UUID — which default auto-login helps supply.
  • • CVE-2026-8481 (July 2026, CVSS 9.9) — /api/v1/validate/code is a code execution sink again. The 2025 fix added authentication, but the endpoint still runs user input through exec(). It is now rated PR:L — authenticated — which is exactly the gate that CVE-2026-9103 removes, and CVE-2026-9198 is the assigned chain that does so.

The trajectory is telling: the same validation endpoint went from unauthenticated code execution, to authenticated code execution, to authenticated code execution behind an authentication bypass. For years each remediation moved the boundary — adding auth, closing a public path — rather than containing execution, until the 1.10.1 fixes finally addressed the validation endpoint itself.

One caveat for precision: the July wave also includes CVE-2026-7873 (CVSS 9.9, published June 30), another authenticated arbitrary-command-execution flaw across the same 1.0.0–1.10.0 range. Whether CVE-2026-7873 and CVE-2026-8481 are distinct issues or overlapping assignments for related behavior is not fully clear from the public records — so read the "recurrence" here as a pattern across closely related CVEs, not necessarily five cleanly independent bugs.

Not Unique to Langflow: Unsafe Deserialization Recurs

The pickle-based flaw in CVE-2026-8476 belongs to a bug class that shows up repeatedly in fast-moving AI infrastructure. The LLM inference framework ktransformers illustrates how persistent it can be: the same unsafe-deserialization pattern drew two overlapping CVE assignments months apart — CVE-2026-26210 (through 0.5.3, April 2026) and CVE-2026-63767 (through 0.6.3, July 2026). An April pull request for the earlier CVE was closed without merging, and the first merged mitigation landed in commit def0f93. Both describe a ZMQ ROUTER socket bound to all interfaces, no authentication, deserializing incoming messages via pickle.loads(); both scored CVSS 9.8 and both unauthenticated. Rather than a bug reintroduced, this reads as one long-unfixed issue — the same primitive as CVE-2026-8476, exposed on the network instead of through a cache file. The lesson is not that one framework is uniquely careless, but that pickle.loads() on untrusted input remains a live pattern worth hunting for.

Investigation Workflow: Find Exposed Langflow Instances

Langflow is self-hosted software, not an appliance. Instances are stood up by developers and data teams, often on cloud VMs or inside internal networks, and — because CVE-2026-33017 was mass-exploited — internet-exposed deployments are a known risk. The first defensive step is inventory: find every Langflow instance you run before an attacker does. Discovery falls into two categories, and the distinction matters legally and operationally.

Passive discovery — Shodan, certificate-transparency logs, and passive DNS — surfaces candidates without touching the target. Active checks — connecting to a port, requesting a page — are direct interactions and should be run only against systems you are authorized to assess. Never request a token from /api/v1/auto_login or post to /api/v1/validate/code on a system you do not own: those mint privileged credentials and execute code, which is intrusion, not reconnaissance.

1. Port Scan: Find Langflow Servers

Langflow serves its web UI and API on a single HTTP port. The documented default host is localhost, but the common ways Langflow gets deployed — Docker port publishing, an explicit --host 0.0.0.0, or a reverse proxy — routinely make it network-reachable, which is how accidental exposure happens:

  • • 7860 — default Langflow HTTP port (web UI and /api/v1; configurable via LANGFLOW_PORT)
  • • 80 / 443 — where Langflow sits behind a reverse proxy (nginx, Traefik, cloud load balancer)
  • • 3000 / 8000 / 8080 — common alternate ports operators choose when remapping

2. HTTP Headers & Endpoints: Fingerprint Langflow

On systems you control or are authorized to test, Langflow exposes distinctive endpoints. None is a perfect fingerprint — combine several and expect false positives:

  • • /docs — the OpenAPI / Swagger UI, which enumerates the API surface including /api/v1/validate/code and /api/v1/auto_login (may be disabled or hidden behind a proxy)
  • • /health — a status endpoint (common to many frameworks, so not unique on its own)
  • • HTML title and app shell referencing Langflow

What this establishes: version plus network exposure indicates potential vulnerability — not confirmed vulnerability, and not AUTO_LOGIN or WEBHOOK_AUTH_ENABLE state, which are server-side settings you can only confirm through your own configuration, not remote probing. Langflow does not advertise its version in HTTP headers, so version confirmation requires the authenticated UI or your deployment records.

3. TLS Inspect: Examine Certificates

Where Langflow is fronted by TLS, pull the certificate and look for internal hostnames — langflow.*, flows.*, ai.*, or generic self-signed / Let's Encrypt certs on non-standard ports. Certificate-transparency logs are a passive source for the same signal and often reveal shadow deployments that inventory tools miss.

4. DNS: Discover Langflow Infrastructure

Query DNS for naming patterns operators use for AI tooling: langflow.*, flow.*, flows.*, agents.*, ai.*. Self-hosted developer tools are frequently given descriptive subdomains that give away their function.

5. CVE Lookup: Track the July Wave

Track the unauthenticated flaws first — CVE-2026-9198, CVE-2026-9103, and CVE-2026-8505 — then the authenticated sinks CVE-2026-8481, CVE-2026-8476, CVE-2026-9135, CVE-2026-14499, and CVE-2026-7755, alongside the historical CVE-2026-33017 and CVE-2025-3248.

Cross-Reference with External Data

  • SHODAN: Search http.title:"Langflow" or http.html:"langflow" to find internet-exposed instances (passive)
  • CVE LOOKUP: Track CVE-2026-9198, 9103, 8505, 8481, 8476, 9135, 14499, 7755, plus CVE-2026-33017 and CVE-2025-3248
  • CISA KEV: Four Langflow CVEs are already KEV-listed (actively exploited): CVE-2025-3248, CVE-2025-34291, CVE-2026-33017, and CVE-2026-55255. The July 2026 CVEs discussed here are not KEV-listed, and no public in-the-wild exploitation of them was found as of July 21, 2026 — but they extend a repeatedly-exploited attack surface
  • NVD: The July Langflow CVEs are IBM CNA records, published July 17, 2026

Remediation

  1. Upgrade to Langflow 1.10.2 or later. The auth bypass (CVE-2026-9103), webhook bypass (CVE-2026-8505), and most of the RCE sinks are fixed in 1.10.1; CVE-2026-14499 requires 1.10.2. Upgrading to 1.10.2+ addresses every Langflow CVE discussed here.
  2. Rotate secrets and revoke tokens after patching. The auto_login flaw mints long-lived superuser bearer tokens; upgrading does not necessarily invalidate tokens already issued. Revoke existing sessions and API keys, rotate the JWT signing secret, and rotate any application or cloud credentials the server could reach. On instances that were internet-exposed pre-patch, treat the host or container as potentially compromised.
  3. Disable AUTO_LOGIN and enforce real authentication. Even on a patched build, AUTO_LOGIN=true means no login is enforced. Set LANGFLOW_AUTO_LOGIN=false, configure a superuser, and require credentials.
  4. Enable webhook authentication. CVE-2026-8505 is exploitable when WEBHOOK_AUTH_ENABLE=False. This default varied across affected releases, so verify that your deployment explicitly sets it to True, which makes webhook flow execution enforce API-key validation.
  5. Get Langflow off the public internet. Whether via container port publishing, an explicit host binding, or a proxy, exposed instances are the risk. Place Langflow behind a VPN, an authenticating reverse proxy, or an IP allowlist. CVE-2026-33017 was mass-exploited specifically because instances were internet-reachable.
  6. Do not rely on feature flags as security boundaries. The Python Interpreter, custom components, and code-validation endpoints execute code by design. CVE-2026-9135 shows allow_custom_components=false was bypassable — restrict who can reach these surfaces at the network and identity layer, not just via a flag.
  7. Hunt for prior compromise. Given the CVE-2026-33017 campaigns, review exposed instances for unexpected processes (especially miners), requests to /api/v1/auto_login or /api/v1/validate/code, new superuser accounts, unfamiliar flows or custom components, child processes, file writes, and outbound connections to unknown hosts.

Every tool used in this investigation — port scan, HTTP headers, TLS inspect, DNS, CVE lookup — runs from your phone in RECON. Get it on the App Store.

Follow @hellorecon for new CVE investigations.

Sources

By Vladimir Slavin · Founder, RECON · [email protected]