CVE-2026-9198: The Two-Endpoint Chain That Hands Unauthenticated RCE in Default Langflow Deployments
On August 4, 2026, the CISA Known Exploited Vulnerabilities catalog added an entry that any team touching AI infrastructure should have printed and pinned to the wall: CVE-2026-9198, a code injection vulnerability in IBM Langflow OSS versions 1.0.0 through 1.10.0 with a CVSS 3.1 score of 9.8. This is not a nominal 9.8 — it is an operational 9.8. A Langflow instance with default configuration, exposed to the network, becomes a machine owned by anyone who knows how to chain two HTTP calls. No credentials required, no social engineering, no sophisticated exploit. Just two endpoints and an exec().
To understand why this matters, you need to understand what Langflow is and why so many companies have it running. Langflow is an open-source platform for visually building LLM applications — chaining prompts, models, tools, and memory into a graph that executes as a pipeline. It is, in essence, the low-code equivalent of what used to be hand-rolled LangChain code. Under the hood it runs Python — and that, as we will see, is exactly where the problem lives. IBM has maintained it as an OSS project for two years, and adoption exploded in 2025 when teams started using it to prototype internal agents, RAG over internal documentation, and connectors to enterprise systems. Many of those installations ended up running on development servers, on lab Kubernetes clusters, on forgotten EC2 instances — exactly the kind of surface that DevSecOps loses track of because it is not production code. But it is. And CVE-2026-9198 proves it.
The vulnerability itself is a case study in how two apparently reasonable design decisions combine to produce a disaster. The first decision lives in /api/v1/auto_login. This endpoint exists because Langflow, during local development, needs to be able to start up and authenticate automatically without the developer having to type credentials. It is a helper for the developer experience. The problem is that the endpoint does not enforce authentication, is not bound to loopback (127.0.0.1), and mints tokens with the SUPERUSER role. For any caller on the network. Not for the legitimate user on that machine — for any IP that knows the endpoint exists. The second decision lives in /api/v1/validate/code. This endpoint exists to validate Python snippets before a user saves them as a custom node in their flow. It is a useful feature: write a function in the visual editor, and Langflow executes it in a controlled environment to catch syntax and runtime errors before persisting it. To validate, Langflow uses Python's built-in exec() function on the code it receives. Combined with a SUPERUSER token obtained for free from the previous endpoint, exec() becomes an open shell into the full operating system. And because Langflow runs as a service, that shell runs with the service's privileges.
The attack chain is trivially reproducible. Step one: GET or POST to /api/v1/auto_login with no authentication headers, no body, nothing. Response: a JSON with a Bearer token marked as SUPERUSER. Step two: with that token in hand, POST to /api/v1/validate/code with a body that contains arbitrary Python code — the canonical example is a reverse shell using socket.connect and os.dup2, but a simple subprocess.run(['whoami']) also works to validate you have execution. Response: the code runs, and depending on the payload, the attacker gets a reverse shell, exfiltrates data, drops a cryptominer, or pivots into the internal network where Langflow is hosted. IBM's disclosure on July 17 already warned that a PoC was functional. On August 4, CISA confirmed: it is being exploited in production, against real instances, right now.
The detail that should worry a CISO most is not the technique — it is the product decision that made it possible. /api/v1/auto_login was not designed with production deployments in mind. It was designed for the developer experience of someone running Langflow on their laptop. And that is exactly the gray zone where DevSecOps loses the most assets: tools that were born for dev, adopted for prototyping, deployed for staging, kept in production because they solved a real problem, and never went through a serious threat model. The Langflow maintainers made a perfectly reasonable decision for a local environment (frictionless autologin) and implicitly extended it to a network service. That is the lesson. You do not need a zero-day for an attacker to get in. You need a component designed for local trust to be reachable from the internet without controls.
For teams that have Langflow running, the first question is whether they have any version between 1.0.0 and 1.10.0 reachable from the network. If the answer is yes, assume compromise until proven otherwise — this is a 9.8 with confirmed KEV, not the time to run a scanner and wait for the report. The immediate mitigation is twofold: upgrade to 1.10.1 or above (the fix shipped June 24), and in the meantime, block access to the /api/v1/auto_login endpoint at the ingress or WAF. If Langflow runs behind a reverse proxy, a rule that returns 403 for /api/v1/auto_login on any request that does not come from 127.0.0.1 breaks the chain before the attacker gets the token. If it runs directly on a port, iptables or a Kubernetes NetworkPolicy limiting the port to known sources is the minimum viable exit.
For detection, look at Langflow's access logs — and here is the second problem, because many OSS installations do not log authentication or code execution by default. If you have a vulnerable version and you are not logging, assume that everything that has happened since August 4 was observed by the attacker, not by you. The minimum signal to look for going forward is any request to /api/v1/validate/code preceded by a request to /api/v1/auto_login from the same IP within a five-minute window. Any request to /api/v1/validate/code that contains words like import os, subprocess, socket, base64, or reverse shell strings in the body. Any unexpected child process running under Langflow's service UID. In EDR, that translates to alerts on Python exec() invoking subprocess or network calls from Python processes that are not your code.
Medium-term hardening is the same you would apply to any AI toolchain exposed to the network: zero trust by default, mandatory authentication on every endpoint, network segregation of the execution plane, and above all, threat modeling before deployment. If your team is going to put Langflow in production, the threat model must answer questions that traditional web app threat models do not contemplate: what happens if an attacker gets arbitrary code execution in the service's Python interpreter? What sensitive data is reachable from that process? What internal networks can it reach? For Langflow specifically, the answer to all of those questions in a default installation is 'everything' — the process runs with full access to the container's filesystem and the network the container is on. That is not acceptable for production without explicit isolation.
The underlying lesson for DevSecOps is that the attack surface expanded without the threat model following it. Every new AI tool we adopt — Langflow, Flowise, n8n with LLM nodes, LiteLLM, VLLM, Ollama — is Python code that connects to the network and executes prompts. Each one with its own list of endpoints, its own admin surface, its own security decisions made by the OSS team that maintains it. The average company's internal vulnerability radar does not cover that territory because it does not know it exists. The threat model does not contemplate it because the team that wrote it thought in terms of Kubernetes, REST APIs, microservices — not in terms of AI runtimes where the user's code is the primary input. CVE-2026-9198 is the first visible crack in that surface. It will not be the last.
Incident and response timeline
The timeline that took CVE-2026-9198 to KEV in less than three weeks from disclosure is an accelerator for how the disclosure chain is working in 2026 — for better and worse. July 17: IBM publishes the advisory and ships Langflow 1.10.1 with the fix. That is an aggressive turnaround, which suggests IBM was already under internal pressure or coordination with security reporters. July 24: first public PoCs begin circulating in exploit research repos and in closed channels. August 4: CISA adds the CVE to KEV with a remediation due date set, forcing all US federal agencies to patch. What that official timeline does not show is everything that happened between July 17 and August 4: massive Internet scans looking for exposed Langflow instances (Shodan reported a spike in queries for the Langflow fingerprint in that window), first confirmed unauthorized accesses in honeypots operated by threat intel firms, and at least two observed campaigns that attempted to deploy XMRig cryptominers via the RCE chain. The window between public disclosure and mass exploitation today, for an AI toolchain vulnerability, is days. Not weeks. Not months.
Incident response procedure if compromise already happened
If your team finds evidence of exploitation — an unexpected child process, an XMRig binary running, outbound traffic to a mining pool, an active reverse SSH session — the first move is containment, not analysis. Isolate the Langflow instance from the network without killing the process (you need the artifact for forensics). Capture memory of the Langflow process if you have tooling that supports it (AVML, LiME, or even a simple dd of /proc/PID/mem before the kill). Capture the entire container if it runs on Kubernetes (kubectl debug + chroot, or crane export of the image if you can). Then, yes, kill the process and block the port. Post-incident analysis is done on a copy, not on the active system that is still compromised. The questions to answer in forensics are: since when? (access logs, syscalls, mtime of touched files), which actor? (source IPs, TTPs, IOCs shared by your threat intel provider), what did they take? (environment variables with possible API keys, access to LLM models that can be used for billing or abuse, data that the Langflow graph processed), where did they pivot? (outbound network logs, new persistent connections, active reverse SSH tunnels). The output of that analysis does not stay inside the IR team — it is translated into detections deployed in EDR, NDR, and SIEM so the next instance compromised by the same actor is detected in minutes, not days.
Supply chain considerations: Langflow as a dependency
There is an angle the official advisory does not cover that matters if your company does not run Langflow directly: it uses it as a transitive dependency. Langflow imports dozens of Python packages, several of which have their own vulnerability histories. An SBOM analysis of the 1.10.0 version shows dependency chains reaching FastAPI, Pydantic, Uvicorn, and httpx — all with CVEs published in the last eighteen months. If your team consumes Langflow as a library inside a larger product, or if you embed it in a container image you then distribute, the exploitable surface is not limited to the direct RCE. An attacker who already has execution can abuse the vulnerable dependencies for persistence (modify requirements.txt at runtime, plant malware in site-packages), for lateral movement (exploit CVE in httpx for SSRF if exposed), or for privilege escalation if the container runs with unnecessary capabilities. That is why the correct remediation is not just an upgrade to 1.10.1 — it is regenerating the container image from scratch with an updated SBOM, verifying signatures if you use cosign or sigstore, and auditing every base image built from the vulnerable version. Images cached in internal registries can keep serving the vulnerable version for weeks if a forced rebuild does not happen.
The design pattern that produced the bug and how to spot it in other tools
The pattern behind CVE-2026-9198 — a convenience endpoint for development that does not enforce controls in production — repeats across dozens of OSS tools. To detect it in your own inventory, the questions to ask are three. First: does the tool have an auto-login, auto-register, or bootstrap endpoint that works without credentials? If yes, is it bound to loopback or reachable from any IP? Second: does the tool execute user-provided code or scripts as part of its normal functionality? If yes, does that code run in the same process as the main service, or in an isolated sandbox? Third: does the official documentation of the tool talk about a 'development mode' versus a 'production mode', and is production mode the default? If the answer to any of the three is the dangerous one, you have a surface that an attacker will eventually find. The Langflow bug was not a minor oversight — it was the inevitable consequence of a design that treated the network environment with the same trust as the local environment. That kind of design decision is not exclusive to Langflow. It is in Flowise, in n8n when Code nodes are configured, in JupyterHub with auth disabled, in Airflow when the Parameterized DAG Executor is used without controls. Auditing AI toolchains in production cannot be done with a generic checklist — it requires understanding the threat model each tool assumes and comparing it to the real threat model of the deployment.
Technical references: NVD CVE-2026-9198 (https://nvd.nist.gov/vuln/detail/CVE-2026-9198), CISA KEV catalog update 2026-08-04, IBM Security Bulletin for Langflow 1.10.1 published 2026-06-24, VulnCheck technical analysis on RCE chains in the AI stack, WhiteHat EU writeup with functional PoC, BleepingComputer report on mass post-disclosure scanning. CVSS 3.1 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. CWE-94 Improper Control of Generation of Code. EPSS 17% as of this writing.