Five AI and ML orchestration platforms entered CISA's Known Exploited Vulnerabilities catalogue between 7 July and 2 September 2026: Langflow twice, then MLflow, Ray, and Kestra.
| CVE | Product | CVSS | Added to KEV |
|---|---|---|---|
| CVE-2026-49869 | Kestra OSS | 10.0 | 2 Sep 2026 |
| CVE-2026-0770 | Langflow | 9.8 | 21 Jul 2026 |
| CVE-2026-64849 | MLflow | 9.3 | 19 Aug 2026 |
| CVE-2025-62593 | Ray | 8.8 | 17 Aug 2026 |
| CVE-2026-59822 | LiteLLM | 8.2 | 2 Sep 2026 |
| CVE-2026-55255 | Langflow | 8.4 | 7 Jul 2026 |
Six confirmed-exploited vulnerabilities, six different tools, one shared category: software that exists to let a team build, run, and orchestrate AI agents and models. None of these are niche. Langflow builds agent workflows visually. MLflow tracks and serves models. Ray is the compute engine several major LLM training and serving stacks run on. Kestra orchestrates data and event pipelines. LiteLLM is a gateway that sits in front of every LLM API call a company makes.
What actually failed, per NVD
The two Langflow CVEs are not the same bug. CVE-2026-0770 is unauthenticated remote code execution through exec_globals — inclusion of functionality from an untrusted control sphere, which is a precise way of saying the application ran code it should never have trusted. CVE-2026-55255 is an IDOR in the /api/v1/responses endpoint: an authenticated attacker executes any flow belonging to any other user by guessing or enumerating that user's flow ID. One is a wall with no door; the other is a door with no lock on which room it opens.
MLflow's bug is textbook SSRF with a twist: the unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint lets an attacker make the server issue a request to an arbitrary internal address and read back both the response status and body — which is exactly what an attacker needs to reach a cloud metadata endpoint and walk out with the instance's credentials.
Ray's vulnerability, per its own advisory language, is exploitable "via Firefox and Safari" against developers running Ray as a local development tool — a browser-based attack chain against a compute engine, not a server-side bug at all. It is the odd one out in this list and worth remembering for that reason: not every AI-infrastructure CVE looks like the others.
LiteLLM's flaw sits in its MCP Streamable HTTP endpoint, which let an unauthenticated caller establish an authenticated MCP session using a fabricated key. Kestra's is OS command injection reached through an authentication filter that whitelisted a path by checking whether it ended in /configs — a suffix check standing in for a security boundary, which an attacker satisfies by choosing a path that also happens to end that way.
Five different root causes. Zero of them are the class of bug a fuzzer reliably finds. All five needed someone to read the code and ask what a legitimate-looking request could be made to do.
Why this category specifically
Every one of these platforms was adopted the way infrastructure gets adopted when a team is moving fast: someone stood up an instance to get a project working, and reachability came along with a docker run and a default port, not with a security review. That is the normal path for developer tooling, and it has always produced this outcome eventually — this is the same story CI servers and artifact registries have been telling all year, arriving now at the layer above them.
The reason it matters more here than it did for a build server: these platforms are frequently one hop from a model's weights, a company's LLM API keys, or every prompt sent through it. An SSRF against MLflow that reaches a cloud metadata service does not stop at MLflow. A hijacked LiteLLM gateway session sees every API key it proxies.
What to check this week
Inventory what you actually have running. Ray, MLflow, and Kestra are frequently deployed by a data science or ML team without the same visibility a security team has into VPN gateways or CI servers. If nobody who reads a CVE advisory knows these instances exist, patching them is not a process failure — it is a discovery failure, and it happens first.
Assume "internal only" is not "unreachable." MLflow's SSRF and Kestra's command injection both matter most when the service is reachable from somewhere an attacker already has a foothold — which for AI infrastructure is frequently a developer laptop or CI runner, not the public internet.
Check what each of these tools can reach, not just what can reach them. An LLM gateway, an orchestration engine, and a model registry are all designed to call outward — to model APIs, to storage, to other internal services. That is also every ingredient SSRF needs.
How Safeguard helps
Safeguard inventories the AI and ML tooling running in an environment the same way it inventories any other component — including instances a security team would otherwise learn about only when a CVE forces the question. Reachability analysis on top of that inventory separates "this CVE exists somewhere in scope" from "this CVE is reachable from where an attacker already stands," which is the distinction that decides whether Ray's browser-based exploit chain or MLflow's SSRF is this week's incident or next quarter's patch ticket.
