On 4 August 2026, CISA added CVE-2026-9198 to the Known Exploited Vulnerabilities catalog, alongside CVE-2026-18556 (N-able N-central) and CVE-2026-34486 (Apache Tomcat). The Federal Civilian Executive Branch remediation deadline was 7 August 2026.

CVE-2026-9198 is an unauthenticated remote code execution vulnerability in IBM Langflow OSS, rated CVSS 9.8. It affects versions 1.0.0 through 1.10.0, with the fix in 1.10.1.

The exploitation chain is close to trivial:

  1. The attacker calls the /api/v1/auto_login endpoint. In default configurations this endpoint mints a SUPERUSER token for any network caller — no credentials required.
  2. With that token, the attacker calls /api/v1/validate/code, which executes arbitrary Python via exec().

That is the entire exploit. No memory corruption, no chaining of subtle logic flaws, no exploit development. Two HTTP requests against a default install.

Telemetry indicates roughly 650 exploitation attempts beginning 6 July 2026, from 244 unique source addresses across 41 countries — a month of activity before the KEV listing.

What Langflow is, and why the blast radius is the story

Langflow is a visual builder for LLM-powered workflows and agents. Users assemble chains of components — model calls, retrieval steps, tool invocations, database lookups — through a graphical interface, then deploy them as APIs.

To do that work, Langflow holds credentials. Specifically, a typical production deployment holds:

  • Model provider API keys — OpenAI, Anthropic, Google, Cohere, or the organisation’s own hosted endpoints.
  • Vector database credentials — Pinecone, Weaviate, Chroma, pgvector connections holding embedded corpora that frequently include proprietary or regulated content.
  • Relational database connection strings — because the whole point of a retrieval-augmented workflow is that it reaches into systems of record.
  • Connector and integration tokens — Slack, Salesforce, SharePoint, Jira, internal APIs.
  • Cloud credentials — for storage access, function invocation, or secrets manager retrieval.

Remote code execution on the Langflow host therefore does not yield a compromised web application. It yields the credential set for every system the AI workflows were wired into, plus the workflow definitions themselves, which document exactly what those systems contain and how to query them.

This is the same structural problem as a compromised RMM platform — the reason the N-able N-central patch bypass mattered so much more than its CVSS score suggested. Orchestration tooling concentrates access by design. When the orchestrator falls, everything it orchestrates is downstream.

The difference, and the reason this one is worse for most organisations, is ownership.

The inventory problem

An RMM server is IT infrastructure. Someone in IT operations owns it, it appears in the CMDB, it is in the patch cycle, and its existence is not in doubt.

Langflow, and the broader category of AI workflow tooling, frequently is not. It arrives through a different door:

  • A data science team spins it up to prototype a retrieval pipeline.
  • A product engineering group deploys it in a development environment that later acquires production data.
  • A business unit stands up an instance on a cloud account outside the central landing zone.
  • It appears as a container in an existing cluster, deployed via Helm chart, with a service exposed more broadly than intended.

In each of those paths, the instance holds production credentials while sitting outside the asset inventory, outside the vulnerability management scope, and outside the change control process. It is shadow AI infrastructure — not in the sense of employees pasting data into a consumer chatbot, which is the version of shadow AI most policies address, but in the more consequential sense of unmanaged systems holding privileged access to regulated data.

The month between first observed exploitation (6 July) and the KEV listing (4 August) is the period in which that distinction determined outcomes. Organisations with the instance in inventory patched on vendor advisory. Organisations without it did not know they had an exposure until CISA published a deadline for a product they were not tracking.

The compliance obligations this triggers

Federal: BOD 26-04

For Federal Civilian Executive Branch agencies, Binding Operational Directive 26-04 applies. The directive requires prioritised rapid remediation of high-risk KEV entries on publicly exposed assets that grant total control of the asset post-exploitation — a description CVE-2026-9198 fits precisely. The 7 August deadline has passed; agencies that could not remediate were required to disconnect affected assets.

The BOD’s asset-discovery obligations are the relevant part for everyone else. A directive that requires you to remediate KEV entries on internet-facing assets is, functionally, a directive to know what your internet-facing assets are. Federal agencies are being held to that standard on a compressed timeline. Contractors and critical infrastructure operators should read it as the direction of travel.

EU AI Act

For organisations deploying AI systems in the EU, the AI Act imposes obligations that this incident touches directly. Article 15 requires high-risk AI systems to achieve an appropriate level of accuracy, robustness and cybersecurity, and to be resilient against attempts to alter their use, outputs or performance by exploiting system vulnerabilities. An unauthenticated RCE in the orchestration layer that lets an attacker modify workflow definitions is squarely within that.

The serious incident reporting obligations under Article 73 apply to providers of high-risk systems where an incident affects health, safety, fundamental rights, or critical infrastructure. An orchestration compromise that allowed manipulation of an AI system’s outputs or exfiltration of the data it processes may qualify.

We covered the state of play on what actually applies as of this month in the August 2026 EU AI Act assessment. The relevant point here is that the Act’s cybersecurity requirements attach to the system as deployed, and the orchestration layer is part of the system regardless of whether the deployer built it or pulled it from a container registry.

GDPR and sectoral data protection

If the Langflow instance held database credentials reaching personal data — and RAG pipelines almost invariably do — then compromise of those credentials is a personal data breach under GDPR Article 4(12) at the point where unauthorised access to the personal data is established or cannot be excluded.

The 72-hour Article 33 clock starts on awareness. The forensic question that determines the notification is whether the attacker used the credentials, and answering it requires logging on the downstream systems, not on Langflow. Organisations that cannot demonstrate what an attacker with valid credentials did in their database are in the position of having to notify on the assumption of worst case.

Under HIPAA, the same logic runs through the breach risk assessment at 45 CFR 164.402: unauthorised acquisition of credentials that permit access to protected health information requires a documented four-factor analysis, and “we have no logs showing use” is not a low-probability finding — it is an absence of evidence.

SEC disclosure

For public companies, a compromise that yields the credential set for multiple production systems is the kind of incident where the materiality determination cannot be deferred indefinitely. The Item 1.05 Form 8-K obligation runs four business days from the determination, and the determination itself must be made “without unreasonable delay.”

The other two KEV entries

CVE-2026-9198 arrived in a batch, and the other two deserve brief attention because they are the same lesson in different clothing:

CVE-2026-18556 — N-able N-central authentication bypass. The original vulnerability whose incomplete fix produced CVE-2026-18577. Both are now on KEV. Any organisation that patched only the second CVE without confirming the first is remediated has a gap.

CVE-2026-34486 — Apache Tomcat missing encryption of sensitive data. Tomcat is the definition of an embedded dependency: it ships inside commercial products, appliances, and internal applications whose owners do not think of themselves as running Tomcat. Remediation requires a software bill of materials capability or a very good dependency scan. Organisations without either will remediate the instances they know about and remain exposed on the ones embedded in vendor products.

Three KEV entries, one common requirement: you cannot patch what is not in your inventory.

What to do about AI orchestration specifically

The generalisable action items:

  1. Discover AI orchestration tooling. Scan for Langflow, Flowise, Dify, n8n, LangSmith deployments, and comparable tools across all cloud accounts, clusters, and development environments. Search container registries and Helm releases, not only running workloads. This is a discovery exercise, and it will find instances that nobody in the security function knew existed.

  2. Treat every discovered instance as a credential store. Enumerate what it holds. Rotate every credential on any instance that was internet-reachable and running an affected version during the exposure window. Rotation is the only reliable remediation for credential exposure; patching stops the next attacker, not the one who already collected.

  3. Remove default-permissive authentication. The auto_login behaviour that makes CVE-2026-9198 trivially exploitable is a default configuration intended to smooth local development. Any AI tooling with a “convenient for prototyping” default has an equivalent, and the prototype configuration is what gets deployed.

  4. Get the orchestration layer off the internet. There is almost never a business reason for the workflow builder to be publicly reachable. The deployed API endpoints may need exposure; the authoring interface and management API do not.

  5. Scope credentials to least privilege per workflow. A Langflow instance holding a database credential with read access to a single view is a materially different incident from one holding an administrative connection string. Most instances hold the latter because that is what was convenient during prototyping.

  6. Put AI tooling in the vulnerability management scope with a named owner. The gap here is organisational, not technical. AI infrastructure that data science teams deploy and security teams do not track will keep producing this outcome.

  7. Log downstream. The forensic answer to “was the credential used” lives in the target system’s audit log. If those logs do not exist or do not retain long enough to cover a month-long exposure window, that is the finding to fix before the next one.

The pattern

The AI governance conversation of the last two years has concentrated overwhelmingly on model behaviour — bias, hallucination, transparency, output controls. Those obligations are real, and frameworks from the EU AI Act to NIST AI RMF to state legislation address them at length.

CVE-2026-9198 is a reminder that AI systems also have conventional infrastructure, and that the infrastructure is where the immediately exploitable risk currently sits. An unauthenticated RCE in a Python web application is not a novel AI risk. It is a 2015-vintage web application vulnerability, in a component that happens to have been handed the keys to everything.

Two things follow. For security functions: AI orchestration tooling belongs in your asset inventory, your patch cycle, and your internet-exposure scanning today, at the same priority as any other system holding production credentials — because that is exactly what it is. For governance functions: an AI governance programme that assesses models but not the platforms running them is assessing the part that is harder to attack, and the KEV catalog has now made that gap a documented, dated, federally-deadlined one.

This article is provided for informational purposes only and does not constitute legal advice.