Langflow CVE-2026-9198 entered the CISA KEV list on 4 August 2026: patch to 1.10.1 and close 3 gaps

Summary. On 4 August 2026 the US Cybersecurity and Infrastructure Security Agency added CVE-2026-9198 to its Known Exploited Vulnerabilities catalog, giving federal civilian agencies until 7 August 2026 to fix it. The bug is an unauthenticated remote code execution flaw in IBM's Langflow OSS, scored CVSS 9.8, affecting every release from 1.0.0 through 1.10.0. IBM published the bulletin on 2 July 2026 and shipped the fix in 1.10.1. There is no workaround. The exploit chains two API endpoints that are both reachable by default: /api/v1/auto_login hands a SUPERUSER bearer token to any network caller, and /api/v1/validate/code runs attacker-supplied Python through exec(). Separately, Palo Alto Networks Unit 42 published a report on 30 July 2026 describing a Chinese-speaking operator who wired DeepSeek into an agent framework and attacked more than 460 targets, including 84 Langflow instances found through FOFA. Those two stories are being reported as one. They are not the same CVE, and conflating them will send your remediation at the wrong version. For Indian teams the arithmetic is blunt: IBM's 2026 Cost of a Data Breach Report puts the average Indian breach at INR 255 million (INR 25.5 crore), up 15.9% year on year, with 26% of malicious breaches in India described as AI-generated.

Self-hosted AI workflow builders are now the softest infrastructure in most engineering organisations. They hold model API keys, database credentials, vector store endpoints and, increasingly, production write access. They were installed by a data team in a hurry. They are running with authentication disabled because that is the default. This article covers what CVE-2026-9198 actually does, why the KEV listing changes your deadline, which Langflow CVE the AI-attacker headlines are really about, and the specific configuration changes that keep the next one from landing.

What CVE-2026-9198 does

IBM's security bulletin, published 2 July 2026 under document ID ibm17278927, describes the flaw as a combination of two distinct issues rather than a single coding mistake.

The first is /api/v1/auto_login. Langflow's auto-login feature exists so that a developer running the tool on a laptop is not asked to sign in. In a default deployment that endpoint issues a superuser bearer token to any caller that can reach the port. No credential, no session, no prior state.

The second is /api/v1/validate/code. Langflow lets you write Python inside a flow, so it needs to check that the code parses. The validator did that by defining the function, and Python evaluates decorators, default arguments and annotations at function definition time. Anything an attacker puts in those positions runs on the host.

Chain them and the sequence is: call auto_login, receive a superuser token, post a Python function whose default argument is a subprocess call, and the code executes with the privileges of the Langflow process. IBM classifies it as CWE-94, improper control of generation of code, with a CVSS 3.1 base score of 9.8 and the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Network attack vector, low complexity, no privileges, no user interaction, and high impact on confidentiality, integrity and availability across the board.

The affected range is Langflow OSS 1.0.0 through 1.10.0. IBM's remediation section names exactly one action, an upgrade to 1.10.1, and its workarounds section says "None". That word matters. There is no environment variable in the affected releases that makes the chain safe while you stay on your current version. Langflow's documentation site currently ships docs for 1.11.x as the stable line, with 1.12.x in preview, so a team patching today is jumping several minor versions, not one.

Why the exec() path is worse than it looks

A normal RCE gives an attacker code execution as whatever user runs the service. In a Langflow deployment that user typically has more than you think. The process reads the environment block that holds your OpenAI, Anthropic and Google API keys. It holds connection strings for whatever database backs the flow store. On a Kubernetes deployment it holds a mounted service account token. The blast radius of a Langflow compromise is not the Langflow container. It is every credential the flows were built to use.

Why the KEV listing changes your deadline

A CVSS 9.8 is a severity opinion. A KEV listing is an observation that somebody is using it.

CISA added three vulnerabilities to the catalog on 4 August 2026: CVE-2026-9198 in IBM Langflow, CVE-2026-18556 in N-able N-central, and CVE-2026-34486 in Apache Tomcat. Federal Civilian Executive Branch agencies had until 7 August 2026 to remediate. The current binding operational directive covering this is BOD 26-04, "Prioritizing Security Updates Based on Risk", which sets vulnerability management requirements for those agencies and uses the KEV catalog as the trigger for rapid remediation.

Private companies are not bound by BOD 26-04. Most cyber insurance questionnaires, enterprise vendor security reviews and SOC 2 change-management narratives now reference the KEV catalog anyway, because it is the only public list that distinguishes "theoretically bad" from "being used today". If a client asks how quickly you close KEV-listed vulnerabilities and your honest answer is "when it comes up in the sprint", that is a finding.

The practical difference between a CVSS score and a KEV entry is a scheduling difference. On CVSS alone, a 9.8 in a tool your data team installed competes for attention with everything else scored 9.x this month. On a KEV entry, it goes to the front.

The Langflow CVE everyone is conflating

This is where the reporting has gone wrong, and where a careless remediation ticket costs you the outage without buying the safety.

The Unit 42 research published on 30 July 2026, authored by Andy Piazza, describes a Chinese-speaking threat actor operating under the aliases knaithe and KnYuan, assessed to be based in Zhuhai, China. The actor connected DeepSeek to the open-source Hermes Agent framework and drove it over Telegram. Unit 42 recovered a full autonomous session dated 7 May 2026 in which, after the initial task, no further operator input appears.

The Langflow vulnerability that agent tried to exploit is CVE-2026-33017, not CVE-2026-9198.

Unit 42's account of that phase is specific. The agent downloaded a public proof-of-concept from GitHub, enumerated 84 Langflow instances through the FOFA search engine using title="Langflow", ran the scanner with --threads 10, and identified exactly one vulnerable target running Langflow 1.3.4. The exploitation attempt then failed. In Unit 42's words, it failed "because the vulnerability requires either auto_login enabled or a public flow ID and the target had neither".

The agent's own reasoning, captured in the recovered logs, reads: "All three Langflow need public flow ID but no auto_login — stuck. Deployments small (84 alive), exploitable probably 0. Search for larger-scale vulns."

It then moved to n8n, where FOFA reported 647,017 instances globally and 25,209 in China. It picked CVE-2026-21858 (CVSS 10.0, patched in n8n 1.121.0) and CVE-2025-68613 (CVSS 9.9, patched in 1.120.4), sampled roughly 100 of the 25,209 Chinese systems, probed about 40 unique addresses, found three running vulnerable versions, and failed again because the exposed form endpoints required authentication.

Two attempts, two failures, both stopped by configuration rather than by patching. Unit 42's conclusion is the sentence worth pinning above your backlog: "Targets with weaker default configurations would have been susceptible."

The manual half of the same campaign did land. Unit 42 confirms data exfiltration from three organisations through Citrix NetScaler CVE-2026-3055 and command execution on 11 Marimo notebook instances through CVE-2026-39987, plus reverse shell attempts against nine Apache Tomcat servers via CVE-2026-34486 and three IKE VPN endpoints via CVE-2026-33824. The report notes that every one of those was public knowledge with a patch available.

If your ticket says "patch the Langflow CVE from the AI hacker story", it is pointed at the wrong advisory. Fix CVE-2026-9198 by version, and fix CVE-2026-33017's preconditions by configuration. They are separate pieces of work and you need both.

What the campaign actually proves about self-hosted agent builders

Strip out the novelty and the Unit 42 findings say three things that matter to anyone running Langflow, n8n, Flowise or a similar builder.

Targeting is now cheap. The agent moved from "find a target class" to "enumerate 84 hosts, score them, discard the product, pick a bigger one" without human input. Unit 42 describes it as executing "hundreds of hours of manual targeting analysis in mere minutes, while also managing its own compute resources". The economics that used to protect a small deployment, namely that nobody would bother, are gone. An 84-host population was assessed and dropped in a single session because a 647,017-host population looked better. Yours is in one of those buckets already.

Default configuration was the control that worked. Not a WAF, not an EDR agent, not a patch. Both autonomous attempts died on a precondition: auto_login was off, and the form endpoints required auth. That is a strong argument for treating the default-hardening checklist below as a security control with a named owner, rather than as setup hygiene somebody does once.

The exploited vulnerabilities were old. Unit 42 records that every successful intrusion in the campaign used a publicly known, already-patched flaw. Nothing in the report describes a zero-day. The gap being exploited is the gap between "a patch exists" and "the patch is applied to the instance the data team stood up in March".

Unit 42 states the overall assessment plainly: "While the observed campaign had limited impacts, the workflow confirms a functional, end-to-end autonomous offensive capability."

The Tomcat entry in that table is the same CVE-2026-34486 that CISA added to KEV alongside the Langflow flaw on 4 August 2026. If you run both products, one campaign report and one KEV update cover two of your remediation items.

The hardening plan

Step one is the version. Everything after it is the configuration that would have stopped the autonomous attempts.

1. Upgrade, and verify what you actually upgraded

            # Confirm the running version before and after
curl -s http://127.0.0.1:7860/api/v1/version

# Pinned upgrade, per IBM's remediation guidance
pip install --upgrade "langflow>=1.10.1"

# Container deployments: pin the tag, never :latest
# docker pull langflowai/langflow:1.11.0
          

Pin an explicit version in your image tag and your requirements file. A floating :latest tag means your rollback target is undefined the next time this happens, and it means an audit cannot tell you what was running on the day of an incident.

2. Turn off auto-login and set real superuser credentials

Langflow's documented behaviour is that LANGFLOW_AUTO_LOGIN defaults to true. Setting it to false requires users to sign in to the visual editor, authenticate as a superuser for certain CLI commands, and use an API key for API requests. Langflow's own documentation recommends that when you set it to false you also set LANGFLOW_SUPERUSER and LANGFLOW_SUPERUSER_PASSWORD explicitly, so the deployment does not fall back to insecure defaults.

            # .env for any deployment reachable by anything other than localhost
LANGFLOW_AUTO_LOGIN=false
LANGFLOW_SUPERUSER=svc-langflow-admin
LANGFLOW_SUPERUSER_PASSWORD=<from your secret manager, not this file>
          

Read that against the Unit 42 finding one more time. The autonomous agent's exploit needed auto_login enabled or a public flow ID. This single line is the control that made an attacker's tooling report "exploitable probably 0" and move on.

3. Stop treating the port as internal

Most Langflow compromises start with an instance that somebody believed was internal. It was reachable from a VPC peering link, a bastion, a misconfigured ingress, or a cloud load balancer that was created for a demo and never deleted.

            # Kubernetes: default-deny egress, then allow only what flows need
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: langflow-egress-lockdown
  namespace: ai-platform
spec:
  podSelector:
    matchLabels:
      app: langflow
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
      ports:
        - protocol: TCP
          port: 443
          

Egress control is the part teams skip, and it is the part that decides whether an RCE becomes a breach. Code execution with no outbound path is an incident. Code execution with unrestricted egress is an exfiltration.

4. Assume the process environment is the real target

Rotate anything the Langflow process could read if you were running an affected version and the endpoint was reachable. That means model provider API keys, database credentials, object storage keys and any OAuth client secrets configured in flows. Mount secrets from a secret manager with short-lived tokens rather than baking them into a .env file that persists in an image layer.

Detection: what to look for before you close the ticket

Patching does not answer the question your security lead will ask, which is whether it was already used against you. Check three things.

Look in your reverse proxy or ingress access logs for requests to /api/v1/auto_login from anything other than your own front end, and for any POST to /api/v1/validate/code. In normal operation, code validation is called by an authenticated user editing a flow in the browser. A validation call arriving without a preceding editor session is worth an hour of somebody's time.

Look at outbound connections from the Langflow host or pod for the period you were on an affected version. New destinations, especially raw IP addresses on port 443 or any non-standard port, are the signal.

Look at your model provider billing. Stolen API keys usually show up as a spend anomaly before they show up anywhere else, and provider dashboards keep usage history longer than most teams keep container logs.

If any of those turn up something, treat it as a credential compromise first and a host compromise second. The same containment order we set out in the keyv npm supply chain containment runbook applies here: contain before you rotate, because rotating first tells the attacker you have noticed while they still hold execution.

India-specific considerations

The cost side of this is no longer abstract for Indian organisations. IBM released its 2026 Cost of a Data Breach Report on 3 August 2026, and the India findings are the ones to put in front of a CFO who is asking why an unbudgeted upgrade window matters.

The average total organisational cost of a breach in India reached INR 255 million (INR 25.5 crore) in 2026, an all-time high and a 15.9% increase over the INR 220 million recorded in 2025. The average breach involved 39,500 compromised records, up from 38,200. Technology companies recorded the second-highest sector average at INR 357 million, behind financial services at INR 409 million.

Two findings speak directly to the situation this article describes. IBM reports that 26% of malicious breaches in India were AI-generated. And organisations with no AI and security automation in their operations paid an average of INR 316 million per breach, against INR 213 million for those with extensive use, while taking 236 days to identify a breach versus 175 days.

"India's accelerating AI adoption is creating immense opportunities for innovation, but it is also enabling cyber threats to evolve rapidly," said Gaurav Agarwal, Vice President, Technology, IBM India and South Asia, in the release accompanying the report.

There is also a regulatory dimension. Under the Digital Personal Data Protection Act 2023, an organisation processing personal data through a flow built in a self-hosted agent builder is a data fiduciary with respect to that processing, and the security safeguards obligation covers the tooling as much as the application. A Langflow instance that reads customer records from a production database is in scope. The DPDP engineering playbook for Indian startups covers how to map that obligation onto infrastructure you did not originally classify as an application.

One more India-specific note on cost control. IBM's report identifies offensive security testing, meaning red teaming and penetration testing, as the largest cost-reducing factor in India, saving an average of INR 24.7 million per breach. An external test that finds your unauthenticated agent builder before an autonomous scanner does is cheap by comparison.

What to change in how you run agent platforms

The specific fix here takes an afternoon. The pattern behind it does not, and it is the part worth arguing for.

Self-hosted AI builders entered most organisations through a data team or an innovation budget, not through platform engineering. They were never onboarded into the asset inventory, so they are absent from patch SLAs, from the vulnerability scanner's scope and from the on-call rota. That is why the Unit 42 campaign found instances running Langflow 1.3.4 in 2026. Nobody owned the upgrade.

Three changes fix the category rather than the instance.

Put every agent builder in the asset inventory with a named owner and a patch SLA that matches its exposure, not its perceived importance. An internal tool with production database credentials is a production system.

Subscribe the owner to the vendor's advisory feed and to the KEV catalog, and treat a KEV listing for anything in your inventory as an automatic priority-one ticket. Both of the KEV entries that matter here, Langflow and Tomcat, landed on the same day.

Make the hardened configuration the deployment default rather than a post-install task. If LANGFLOW_AUTO_LOGIN=false is in the base Helm values, no future instance ships with the precondition an attacker needs. The broader control set for this is in our writeup on AI agent security and prompt injection guardrails, and the governance layer that assigns these owners in the first place is covered in enterprise AI agent governance layers. For teams still deciding which of these platforms belongs in production at all, our guide to enterprise AI agents in production sets out the selection criteria.

The real cost is usually the inventory gap, not the patch.

FAQ

How eCorpIT can help

eCorpIT is a CMMI Level 5, ISO 27001:2022 certified engineering organisation in Gurugram, and our senior engineering teams run this exact work for clients: inventorying self-hosted AI tooling, patching it to a supported release, applying the hardened configuration as a deployment default, and reviewing logs for prior exploitation. We design applications aligned with DPDP Act 2023 requirements, so the same review covers whether an agent builder touching personal data has the safeguards a data fiduciary is expected to have. If you have a Langflow, n8n or Flowise instance nobody owns, contact us and we will scope a review against the controls in this article.

References

1. IBM, Security Bulletin: Unauthenticated Remote Code Execution via Auto-Login Bypass and Code Validation, published 2 July 2026.

1. MITRE, CVE-2026-9198 CVE record.

1. MITRE, CWE-94: Improper Control of Generation of Code ('Code Injection').

1. CISA, CISA Adds Three Known Exploited Vulnerabilities to Catalog, 4 August 2026.

1. CISA, Known Exploited Vulnerabilities Catalog.

1. CISA, BOD 26-04: Prioritizing Security Updates Based on Risk.

1. Palo Alto Networks Unit 42, Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks, published 30 July 2026.

1. The Hacker News, CISA Flags Langflow RCE, Tomcat, and N-central Flaws as Actively Exploited, 5 August 2026.

1. Langflow, API keys and authentication.

1. Langflow, Environment variables.

1. PyPI, langflow package releases.

1. IBM India Newsroom, India Records Its Highest Average Cost of a Data Breach at INR 255 Million (INR 25.5 Crore) in 2026, 3 August 2026.

1. IBM, Cost of a Data Breach Report.

Last updated: 7 August 2026.