The New Soft Perimeter: Six Langflow CVEs in Fifteen Months, and What AI Dev Tooling Got Wrong

Six Times in Fifteen Months

Between May 2025 and August 2026, Langflow — an open-source platform for building AI agents and workflows visually — was added to the CISA Known Exploited Vulnerabilities catalog six times. Four of those additions came in 2026 alone, and the most recent, CVE-2026-9198, landed on 4 August 2026 with a three-day federal remediation deadline.

That cadence puts Langflow in company it would not choose. It is the trajectory Ivanti's management products followed in 2023–24 and Zimbra's webmail followed from 2022: a single product becoming a standing fixture in the catalog, not through one catastrophic bug but through a repeating architectural weakness that each fix addresses narrowly and none of them addresses structurally.

Langflow is not alone, and that is the more important point. Marimo reached KEV in April 2026 with a pre-auth RCE. Ray was added on 18 August 2026. These are all tools from the same generation and the same design tradition — AI developer infrastructure built to run arbitrary user code, shipped with authentication treated as someone else's problem, and then deployed on the open internet by users who assumed the defaults were safe.

What These Tools Are, and Why the Defaults Look the Way They Do

Langflow is a visual builder for LLM applications. Users drag components onto a canvas, wire them together into a "flow," and Langflow executes it. Crucially, users can write custom Python components — the platform's main selling point over rigid no-code tools — which means the server is designed from the outset to accept Python source from a user and run it.

Ray is a distributed compute engine for AI and ML workloads, sometimes described as "the Kubernetes of AI." Its Jobs API accepts a job definition and executes it across a cluster. Marimo is a reactive Python notebook, in the Jupyter tradition, where executing user code is the entire product.

For all three, arbitrary code execution is not a vulnerability — it is the feature. This is the fact that makes the cluster coherent. There is no version of these products in which the server does not run code the user supplied. The security question was never "should this execute code?" but "who is allowed to ask, and what does the code run as?" That second question is where the failures concentrate.

The design tradition compounds it. These tools grew out of research and prototyping contexts, where the operating assumption was a single developer on a laptop or a team on a trusted internal network. Under that assumption, authentication is friction and sandboxing is overhead. Ray's maintainers made the assumption explicit, documenting that Ray requires a trusted network — a position that became contentious when thousands of Ray clusters turned out to be facing the internet. Langflow shipped an auto_login endpoint for exactly the same reason: so a developer running it locally would not be nagged for credentials.

Then the tools got popular, moved to cloud infrastructure, and kept their defaults.

The Langflow KEV Record

Note the deadlines. Four of the six carry a remediation window of three days or less — CISA's most aggressive tier, reserved for internet-facing software under confirmed active exploitation.

Note also the right-hand column. Five of the six paths end at the same place.

The Sink That Would Not Close

The technically interesting thing about this cluster is that it is not six unrelated bugs. It is a series of different routes to one destination: Python's exec(), called on user-supplied source, unsandboxed, in the Langflow server process.

CVE-2025-3248 (April 2025) is the direct route. POST /api/v1/validate/code accepted a JSON body of Python source, passed it to exec() with no sandboxing and no authentication, and returned the result. A single unauthenticated request was full server compromise:

POST /api/v1/validate/code HTTP/1.1
Host: <target>:7860
Content-Type: application/json

{"code": "import subprocess; subprocess.run([...])"}

The fix added authentication to the endpoint.

CVE-2026-33017 (March 2026) went around it. A different endpoint — POST /api/v1/build_public_tmp/{flow_id}/flow — is designed to be unauthenticated, because public flows are a legitimate feature. But when the optional data parameter was supplied, the endpoint used attacker-controlled flow data instead of the stored flow from the database. Since flow definitions contain Python in their node definitions, that data travelled through the graph builder — create_graph() → Graph.from_payload() → eval_custom_component_code() → create_class() → prepare_global_scope() → exec() — and arrived at the same sink by a longer road. Adding authentication to the first endpoint did nothing about this one. The fix removed the data parameter in v1.9.0.

CVE-2026-0770 (added July 2026) returned to /api/v1/validate/code and found it still reachable: the endpoint accepted an exec_globals parameter passed straight into exec() inside validate_code(), with no restriction on available builtins and — in default container deployments — running as root. Trend Micro's Zero Day Initiative tracked it as ZDI-CAN-27325.

CVE-2026-9198 (added August 2026) chained two features, neither of them a memory-safety bug:

1. GET /api/v1/auto_login — the local-development convenience endpoint — was not bound to loopback and enforced no authentication of its own. Any client that could reach the service received a valid JWT with SUPERUSER privileges.
2. POST /api/v1/validate/code trusts the caller's bearer token. Which link one had just handed out for free.

Two HTTP requests, no exploitation skill required, trivially scriptable for mass scanning — which is exactly what the public PoCs did.

The remaining two entries are authentication and authorization failures that reach the same value. CVE-2025-34291 combined a wildcard CORS policy that also permitted credentials, a refresh_token_lf cookie set SameSite=None, and a /api/v1/refresh endpoint with no CSRF protection — letting any website steal a logged-in user's tokens cross-origin and then use them to reach the code path. CVE-2026-55255 is an IDOR: authorization decided on a user-controlled flow UUID with no ownership check, so an attacker could enumerate flow IDs and replay one against /api/v1/responses to execute another user's flow — and exfiltrate the API keys embedded in it. That one is examined in detail in Securing Agentic AI Platforms as a textbook confused-deputy failure.

The pattern across all six: each fix addressed the route, not the destination. An unsandboxed exec() on user input remained reachable in the codebase, and attackers kept finding new ways to reach it. This is the same dynamic as Zimbra's Classic UI sanitizer producing seven XSS CVEs — a single unsafe primitive that every individual patch leaves in place.

Beyond Langflow: The Same Assumption, Different Products

Marimo — CVE-2026-39987, KEV 23 April 2026, CVSS 9.8. A pre-auth RCE via an unauthenticated terminal WebSocket. The exploitation data is the most instructive in this cluster: Sysdig's threat research team recorded the first exploitation attempt 9 hours and 41 minutes after the advisory was published, with a complete credential theft operation executed in under three minutes. No public PoC existed — the attacker built a working exploit from the advisory text. Over the following four days Sysdig logged 662 exploit events from 11 source IPs across 10 countries, with reverse shells, credential extraction, DNS exfiltration, and lateral movement into co-located PostgreSQL and Redis using leaked credentials.

Ray — CVE-2025-62593, KEV 18 August 2026, CVSS 8.8. The most conceptually interesting of the group, because it defeats the mitigation everyone else in this space relies on. Ray's Jobs API is unauthenticated by design; the defence against browser-originated attacks was a check that rejected requests whose User-Agent began with Mozilla. But the fetch specification permits scripts to set that header, and Firefox and Safari implement it to spec. Combined with DNS rebinding to defeat the same-origin policy, an attacker's web page can reach a Ray instance bound only to localhost and submit a job containing arbitrary shell commands.

That last point deserves emphasis. Every tool in this cluster leans on "don't expose it to the internet" as the answer. Ray demonstrates that a developer's browser is itself a route into the localhost-bound service — the network boundary was never where anyone assumed it was. Ray fixed it in 2.52.0, released November 2025, nine months before the KEV listing.

Ray also carries the longest exploitation history here, though under a different CVE. Oligo Security's ShadowRay campaign (March 2024) documented mass exploitation of CVE-2023-48022 — the same unauthenticated Jobs API — for cryptomining, secret theft, and AI-workload data exfiltration. ShadowRay 2.0, in late 2025, tracked continued exploitation by the RondoDox, MooBot, and KmsdBot families assembling a self-propagating botnet. CVE-2025-62593 is a distinct vulnerability, but it extends the same unauthenticated-API problem to instances ShadowRay could never reach.

What Attackers Actually Want

Across this cluster the payoff is consistently credentials, not compute.

The earliest Langflow campaigns were the exception that proves it: Fortinet's FortiGuard Labs documented XMRig cryptominers deployed to compromised Langflow instances in 2025, taking advantage of the high-CPU cloud infrastructure AI workloads run on. That is the obvious play, and it is no longer the main one.

A compromised Langflow, Ray, or Marimo instance is rarely valuable for its own hardware. It is valuable for what it holds: model-provider API keys that can be resold or run up enormous inference bills, database and SaaS credentials for the systems the flows connect to, and cloud credentials from the instance metadata service that lead to the rest of the account. Sysdig's Marimo data shows the pattern explicitly — credential extraction inside three minutes, then lateral movement into co-located data stores using what was found.

The operational consequence: treat a compromise of any of these platforms as a credential-theft incident first and a host-compromise incident second. Rebuilding the host does not invalidate the keys.

What Defenders Must Do

1. Inventory this tier — you probably do not know where it is. AI developer tooling arrives through data science and ML teams, not through IT procurement. It gets deployed to cloud accounts on default ports (Langflow 7860, Ray dashboard 8265) by people reasonably focused on shipping a model. Scan for it before deciding you do not have it.

2. Assume nothing in this category is safe to expose. Not the dashboard, not the API, not "just the read-only bit." Put every one of these services behind SSO or a VPN. Roughly every CVE in this cluster becomes unexploitable-at-scale the moment the service stops answering unauthenticated requests from the internet.

3. Do not treat localhost binding as a security boundary. CVE-2025-62593 is the proof. Enable DNS rebinding protection at the resolver — blocking external DNS answers that resolve into RFC1918 or loopback space (dnsmasq --stop-dns-rebind or the equivalent in Pi-hole, Unbound, or a corporate resolver) — and be conscious that a developer browsing the web with a local AI service running is an exposed configuration.

4. Run these services with the least privilege they will tolerate. Several of these CVEs are rated 9.8 partly because the default container runs as root. Non-root containers, read-only filesystems where possible, and no ambient cloud credentials on the instance turn a full compromise into a smaller one.

5. Get the credentials out of the application. The reason these compromises hurt is that the platform stores long-lived provider keys and database credentials. Use a secrets manager with short-lived, scoped, individually revocable credentials, so that a compromise produces a rotation task rather than a breach.

6. Rotate on any advisory, before you finish patching. Given how fast exploitation follows disclosure here — under ten hours for Marimo — the window in which you were vulnerable-but-unpatched should be assumed to have been used. Rotate model-provider keys, database credentials, and any connector tokens the platform held.

7. Track these products on an expedited patch track. Four of the six Langflow entries carried three-day federal deadlines. Standard monthly change control does not survive contact with this cadence.

The Cluster Is Not Finished

The conditions that produced these fifteen months are unchanged. Executing user-supplied code remains the core function of every product here, which means the dangerous sink cannot be removed — only guarded, and the Langflow record shows how many distinct routes to one exec() a determined researcher can find. Adoption continues to outrun the security maturity of the tooling, and the deployment pattern — cloud-hosted, internet-reachable, holding credentials to everything the model touches — is if anything becoming more common.

Langflow is the current headline because it is popular enough to attract sustained attention. The structural problem belongs to the category. The organisations that come through this well will be the ones that stopped treating AI developer tooling as a niche internal dev tool and started treating it as what it operationally is: an internet-facing application server that runs untrusted code and holds the keys to the data estate.