Langflow CVE-2026-0770: Unauthenticated Root RCE in LLM Tooling (CVSS 9.8)

Langflow is a visual LLM application builder — a drag-and-drop interface for composing LangChain chains without writing code. Like all the AI tooling that emerged over the past two years, it saw explosive adoption: deployed fast, often exposed, and rarely put through a security review.

Two Langflow vulnerabilities joined the CISA KEV catalog in July 2026, including an unauthenticated RCE that executes code as root (CVSS 9.8).

The detail that should raise an eyebrow: CVE-2026-0770 was published on January 23, 2026 and only entered KEV on July 21 — six months later. Such a gap usually means one thing: the exposed population was still large enough in July to warrant an alert.

The Two CVEs

CVE-2026-0770 — exec_globals to root

NVD description:

Langflow exec_globals Inclusion of Functionality from Untrusted Control Sphere Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Langflow. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the handling of the exec_globals parameter provided to the validate endpoint. The issue results from the inclusion of a resource from an untrusted control sphere. An attacker can leverage this vulnerability to execute code in the context of root.

The mechanism

Langflow's validate endpoint exists to validate code — typically the Python snippets a user embeds in flow components. To do that, it necessarily evaluates them.

The exec_globals parameter controls the global namespace supplied to that evaluation. By letting the caller define that namespace, the application lets them inject arbitrary references into the execution context — notably reconstructing access to the import and system-execution primitives the validation was supposed to withhold.

Two aggravating factors compound it:

• No authentication required on the endpoint
• Execution as root — Langflow is overwhelmingly deployed in Docker with the default user, i.e. root

The underlying problem with this class of tool

Langflow, like most LLM flow builders, has an uncomfortable property: executing arbitrary user-supplied code is its purpose, not its bug. A custom Python component in a flow is code the application must run.

The security of these tools therefore rests entirely on the assumption that "the user is trusted" — an assumption that collapses the moment the instance is reachable without authentication, or an authorization bypass exists. Which brings us to the second CVE.

CVE-2026-55255 — running other people's flows

NVD hasn't published a score. CISA description:

Langflow contains an authorization bypass through user-controlled key vulnerability which allows an authenticated attacker to execute any flow belonging to another user by specifying the victim's flow ID in the request.

The pattern is classic — a direct object reference without ownership checking (IDOR): the application verifies you're authenticated, but not that the flow_id you're requesting belongs to you.

The impact is specific to the LLM context, and it's underestimated if read as a mere IDOR. Running another user's flow means:

• Burning their LLM API keys — every execution bills the flow's owner, not the attacker
• Accessing the data the flow handles: vector stores, indexed documents, connectors into internal systems
• Using the credentials embedded in the flow (database connections, third-party APIs, webhooks)
• On a multi-tenant instance, crossing the tenant boundary

An enterprise LLM flow typically contains far more than a prompt: authenticated connectors into the corporate estate, access to a vector store fed with internal documents, and high-value API keys.

Affected Products and Versions

For CVE-2026-55255, NVD doesn't yet expose the fixed version — check the project releases.

Check your version:

# Docker
docker inspect langflow --format '{{.Config.Image}}'

# Pip
pip show langflow | grep -i version

# Via the API
curl -s http://localhost:7860/api/v1/version

Exploitation and Impact

Why AI tooling is mass-scanned

This tool category concentrates every risk factor:

• Fast deployment, deferred hardening — installed to prototype, the instance stays
• Frequent exposure — to share a demo with the team or a client, it goes on a public IP
• Authentication often disabled in development, then forgotten
• Root execution in default Docker images
• High-value secrets: OpenAI, Anthropic, Bedrock keys, vector store and connector credentials

Post-compromise, the result reaches well past the server: LLM API keys resell, and an active key can burn thousands in credit within hours.

Attack chain

1. Discovery of an exposed Langflow instance (the UI is identifiable by its HTTP signature)
2. CVE-2026-0770: request to validate with a crafted exec_globals → code execution as root, no account
3. Extract environment variables and the Langflow database → LLM API keys, connector credentials
4. Enumerate and execute existing flows (CVE-2026-55255 if an account was obtained)
5. Pivot into the internal systems reached by the flows' connectors
6. Persistence: create a malicious webhook-triggered flow, indistinguishable from legitimate use

Detection and IOCs

Application logs

# Calls to the validate endpoint — rare in normal use
docker logs langflow 2>&1 | grep -iE "validate|exec_globals"

The validate endpoint is hit while editing components in the UI. A volume of calls with no matching editing session, or calls containing exec_globals, is abnormal.

Reverse proxy logs

grep -E "POST .*(validate|/api/v1/validate)" /var/log/nginx/access.log | \
  grep -vE "^(10\.|172\.16\.|192\.168\.|127\.)"

Any call from an external IP warrants investigation.

On the container

# Unexpected child processes
docker exec langflow ps -ef | grep -vE "python|uvicorn|gunicorn|ps|grep"

# Recent files
docker exec langflow find /tmp /app -type f -mtime -60 -newer /etc/hostname 2>/dev/null | head -30

The financial signal

Often the first indicator noticed in practice: an unexplained rise in billing at OpenAI, Anthropic or Bedrock. Review your consumption over the last six months — the CVE has been public since January.

Flow audit

List existing flows and look for ones nobody claims, particularly webhook-triggerable ones. That's the stealthiest persistence mechanism on this kind of tool.

Mitigation and Patch

1. Update

# Docker
docker pull langflowai/langflow:1.7.3
docker compose up -d

# Pip
pip install --upgrade "langflow>=1.7.3"

2. Take the instance off the internet

This is the highest-value mitigation, here and for the next CVEs in this tool category. A Langflow instance has no business on a public IP. VPN, mTLS, or an authenticating proxy.

3. Enable authentication and verify it's actually enforced

Many instances run with auto-login enabled, inherited from development mode. Confirm authentication is required on every endpoint, not just the UI.

4. Don't run as root

# docker-compose.yml
services:
  langflow:
    user: "1000:1000"
    read_only: true
    tmpfs:
      - /tmp

This doesn't fix the CVE but substantially reduces exploitation impact — the difference between "code executed as root" and "code executed as an unprivileged account in a read-only container."

5. Incident response — the CVE has been public since January

If your instance was exposed since January 2026, treat compromise as plausible:

1. Rotate every LLM API key handled by Langflow, at the provider
2. Rotate the connector credentials used by your flows (databases, internal APIs, webhooks)
3. Audit LLM billing for the last six months
4. Review the flow list and delete unclaimed ones
5. Rotate the credentials of the Langflow database itself

Why Continuous Monitoring of Your AI Stack Matters

AI tooling gets deployed faster than it gets hardened. Langflow, Flowise, Dify, AnythingLLM, LiteLLM, Ollama, vLLM: these components handle very high-value API keys and authenticated connectors into the corporate estate, yet appear in no classic security inventory. They aren't in the CMDB, they have no declared owner, and often the security team doesn't know they exist.

CVE-2026-0770 illustrates it: published in January, KEV-listed in July — six months during which an unauthenticated root RCE was publicly documented and exploitable.

With cveo.tech, inventory your AI infrastructure tools alongside your business applications and get automatic alerts whenever a critical CVE targets one of your exact versions — so you don't discover the flaw six months after publication, via your OpenAI invoice.