Low-code AI tools are often treated like developer conveniences. Langflow demonstrates why that assumption is dangerous: a workflow builder that can execute Python, hold model-provider keys, and connect to databases is an execution environment with valuable secrets.

CVE-2026-9198 chained two exposed behaviors in default deployments. A remote caller could obtain a superuser token through auto-login and then reach a code-validation endpoint whose use of Python exec() allowed code to run while a submitted function was being defined. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on August 4, 2026.

TL;DR

  • Default Langflow 1.0.0 through 1.10.0 deployments are affected by CVE-2026-9198.
  • Upgrade to at least 1.10.1 for this CVE; use 1.10.2 or later because IBM fixed additional serious Langflow flaws there.
  • Do not expose Langflow directly to the internet. Put it on a private development network with explicit authentication and restricted egress.
  • If a vulnerable instance was reachable, inspect workflows and host activity, then rotate model, cloud, database, and application secrets.

🔴 RED TEAM — From Anonymous Request to Python Execution

According to IBM’s advisory, the first step abuses /api/v1/auto_login. On affected default deployments, a network caller can receive a bearer token with SUPERUSER privileges without first proving identity.

The second step reaches /api/v1/validate/code. The endpoint uses Python’s exec() to validate submitted code. Even if the intended body of a function is never called, Python evaluates decorators, default argument expressions, and annotations when defining it. Attacker-controlled expressions in those positions therefore turn “validation” into execution.

Unauthenticated caller reaches Langflow
        ↓
/api/v1/auto_login returns a superuser bearer token
        ↓
Token authorizes access to /api/v1/validate/code
        ↓
Python evaluates attacker-controlled definition-time expressions
        ↓
Code runs with the Langflow service account's access and secrets

The interesting lesson is not simply “never call exec().” Security controls must model when a language evaluates each part of submitted code. Parsing a function and refraining from calling its body is not safe when definition itself has side effects.

Why Compromise Can Spread Beyond Langflow

A practical Langflow deployment may connect to model providers, vector databases, object stores, source repositories, internal APIs, and conventional databases. Its environment variables and saved components may contain the credentials for those systems. Remote code execution can therefore become data theft or a pivot into services that were never publicly reachable.

The exact blast radius depends on the credentials and network access assigned to the process. That is something defenders can control before the next bug arrives.

🔵 BLUE TEAM — Patch, Contain, and Investigate

1. Upgrade Past Both Security Boundaries

IBM lists 1.10.1 as the fix for CVE-2026-9198 and provides no workaround. However, a later IBM bulletin fixes additional critical issues in 1.10.2. Install 1.10.2 or a newer supported release rather than stopping at the first minimally fixed version.

Record the version running inside the actual container or environment. A newly pulled image does not update an old container that is still running, and a corrected lockfile does not prove that production was redeployed.

2. Remove Direct Public Exposure

Bind Langflow to a private interface or place it behind a private gateway. Limit access to authorized developers through a VPN or identity-aware proxy, and enforce authentication independently of a development-mode convenience setting.

A reverse proxy is a useful additional boundary, but it is not a substitute for upgrading. Misrouted internal traffic, stolen proxy sessions, alternate ports, and server-side requests can bypass assumptions built around “nobody knows the URL.”

3. Hunt at Both HTTP and Process Layers

Review reverse-proxy and application logs for access to the two affected endpoints, particularly from unfamiliar addresses or at unusual times. Then correlate those requests with:

  • new or modified flows, components, users, and credentials;
  • unexpected child processes spawned by the Langflow Python process;
  • outbound DNS, HTTP, or socket connections to new destinations;
  • access to environment files, cloud metadata, credential stores, or mounted source code;
  • subsequent use of model-provider, database, cloud, or repository tokens.

Absence of one literal payload is weak evidence. Decorators, defaults, and annotations give an attacker several syntactic ways to trigger evaluation.

4. Rotate What the Service Could Read

If exploitation cannot be excluded, replace secrets available to the Langflow process: model API keys, database credentials, cloud tokens, signing secrets, webhook secrets, and source-control tokens. Revoke old values rather than only adding new ones, and check the providers’ audit logs for use outside the expected workload.

Rebuild the service from trusted artifacts and review stored workflows before importing them. Retaining an attacker-modified flow can restore unwanted behavior after the vulnerable package is gone.

Build the Safer AI Workbench

Run AI workflow tools as untrusted development services. Use a dedicated service account, read-only credentials where possible, short-lived tokens, separate development data, and outbound allowlists. Never give a visual workflow builder broad production access merely because the interface looks less dangerous than a terminal.

That architecture turns the next application flaw from “all connected systems exposed” into a contained development incident.

Sources