The ML tools your data team installed are on CISA's exploited list

On Monday 17 August 2026, CISA added a Ray vulnerability to its Known Exploited Vulnerabilities catalog and gave federal agencies until Thursday to fix it. Two days later it added an MLflow vulnerability with a deadline of 2 September.

Neither of those is a model. Neither is an AI vendor most enterprises have a contract with. Both are open source components that a data science team installs on its own, on infrastructure the company already owns, without a purchase order and usually without a ticket.

That is the part worth sitting with. The catalog of vulnerabilities the United States government has confirmed are being exploited right now contains 1,675 entries. Four of them are AI platform tools, and all four were added in the last four months.

What actually got added

The four entries, in the order CISA added them:

Source: CISA Known Exploited Vulnerabilities Catalog, version 2026.08.24.

The technical detail matters here, because it explains what an attacker actually gets.

The MLflow flaw (CVE-2026-64849, CVSS 9.3) sits in an unauthenticated endpoint, POST /api/2.0/mlflow/webhooks/{id}/test. MLflow validates the webhook URL you supply, then follows redirects without pinning the address it just validated. An attacker points the webhook at a server they control, that server redirects to the cloud metadata endpoint, and MLflow returns the response body. On a default cloud instance profile, that response contains temporary IAM credentials. Fixed in 3.15.0.

The Ray flaw (CVE-2025-62593, CVSS 9.4) is stranger and more specific. Ray defended its dashboard against browser-based attacks by checking whether the User-Agent header starts with "Mozilla". The fetch specification permits scripts to modify that header, so the defense does not hold. Combine that with DNS rebinding and a developer who visits a malicious page, or is served a malicious ad, and an attacker reaches the Ray cluster from inside that developer's browser. Fixed in 2.52.0.

Both LiteLLM flaws are worth reading together. CVE-2026-42208 put a caller-supplied API key straight into a database query instead of parameterising it, reachable unauthenticated through the error-handling path on any route including POST /chat/completions. NVD's own words for the consequence: unauthorised access to the proxy "and the credentials it manages." CVE-2026-42271 let any authenticated user, including low-privilege internal keys, spawn arbitrary subprocesses on the proxy host through an MCP preview endpoint that took command, args and env from the request body with no role check.

Both were fixed in the same release, 1.83.7. Anyone who upgraded once in May was clear of both.

The remediation window is a formula now

Two of these carried a three-day deadline and two carried fourteen. That difference is not a judgment call, and understanding the rule is useful whether or not you are a federal agency.

On 10 June 2026, CISA issued Binding Operational Directive 26-04, which revoked and replaced BOD 22-01, the 2021 directive that created the KEV catalog. The new directive sets remediation deadlines from four inputs: whether the asset is publicly exposed, whether the CVE is in the KEV catalog, whether an adversary can automate every step of exploitation, and whether successful exploitation yields partial or total control of the asset.

For anything already in the KEV catalog, the relevant rows are these:

Ray and the LiteLLM SQL injection are code execution and credential compromise, which is total control, so they land on three days. The MLflow flaw returns a response body to an attacker, which is information exposure rather than control of the software, so it lands on fourteen.

The background section of the directive states the reasoning plainly: threat actors' "use of AI may further narrow the time defenders have to react between patch release and possible exploitation." That is a binding federal directive naming AI as a reason to compress patch windows. It is worth quoting to a board that thinks of AI risk as a model behavior question.

For contrast, the same catalog contains two Apache Airflow entries added in January 2022, under the old regime. Their deadline was 18 July 2022. A window of 181 days for the previous generation of pipeline tooling, against three days for this one.

Nobody can tell you which one matters next

The most useful number in this whole picture is not the CVSS score. It is the gap between the day a vulnerability became public and the day CISA confirmed it was being exploited, because that gap is all the warning anyone gets.

LiteLLM SQL injection0 days

MLflow SSRF2 days

LiteLLM command injection31 days

Ray code injection264 days

Ray's flaw was published on 26 November 2025 and sat in the catalog of known-but-not-known-exploited issues for 264 days. A team that triaged it in December and decided it could wait was, for eight months, correct.

MLflow's was published on 17 August 2026 and was confirmed as exploited 48 hours later.

LiteLLM's SQL injection had no gap at all. It entered the KEV catalog on the same day it entered the public record, which means it was already being used against real systems before anyone outside the attacker knew it existed.

There is no pattern in 0, 2, 31 and 264 that lets you predict the next one. Any process that waits for the KEV listing before caring is a process that had three days of notice on two of these four, and none on a third.

Why this class of tool escapes the process

Most enterprises run a decent vulnerability management program. The reason these tools slip through it is organisational rather than technical.

MLflow, Ray, LiteLLM and their neighbours arrive differently from the rest of the estate. A data scientist installs MLflow to track experiments. A team stands up Ray to schedule a training job. Someone adds LiteLLM so their code can call four model providers through one interface. None of this passes through procurement, because none of it costs anything. None of it lands in the CMDB, because nobody filed a change. None of it has a named owner on the platform team, because the platform team was never told.

The result is a set of services with web interfaces on predictable ports, holding credentials to the cloud account, absent from the asset inventory that drives patching. When a CVE lands, the scanner does not flag them, because the scanner does not know they exist.

This is the same failure that produced the LiteLLM supply chain compromise earlier this year, where two backdoored packages were live on PyPI for roughly forty minutes and automated builds carried them into thousands of pipelines. The exposure was never a decision anyone made. It was a default, executing faster than any human could review it.

It is also why the "is this an AI risk" framing gets in the way. If the question at the security review is whether the model can be jailbroken, this class of exposure never comes up. The model is fine. The Postgres credentials sitting in the proxy's environment are the problem.

What to do Monday

Four things, in rough order of value per hour spent.

Find the tools. Scan internal ranges for the default ports and interfaces this class of software ships with: MLflow on 5000, Ray dashboard on 8265, Jupyter on 8888, LiteLLM on 4000, plus vector databases and notebook servers. Do this from inside the network, not from the perimeter, because the assumption that these are internal-only is exactly the assumption DNS rebinding and SSRF are built to defeat. Every result gets a named owner and an entry in the asset inventory. That single step is most of the fix.

Check versions against the four CVEs above. MLflow at or above 3.15.0. Ray at or above 2.52.0. LiteLLM at or above 1.83.7, which covers both of its entries. This is an afternoon of work and it closes the four issues the US government has confirmed are being exploited.

Rotate what these services can reach. For every instance found, list the credentials it holds and when they were last rotated. Where MLflow or a similar service runs on a cloud instance with a role attached, check whether IMDSv2 is enforced, since the MLflow flaw is only interesting to an attacker if the metadata endpoint answers. Scope the roles down to what the workload actually needs.

Set the standing rule. Any AI or ML tool that runs on company infrastructure gets an owner and a patch process before it gets data. Not a committee, and not an approval queue that teams will route around. A one-line registration and a named human.

None of that requires a new security product, which is the useful part. The tools already exist and the scanning already runs. What is missing is the list of things to point them at.

The wider point is smaller than it looks. AI governance programs spend most of their attention on model behavior, vendor questionnaires and acceptable use, all of which matter. Meanwhile the fastest-moving exposure in most estates is a piece of open source software with a web interface, installed by someone doing exactly their job, holding a credential to the cloud account and running a version from last year.

Ask for the list. The conversation it starts is more productive than the one about jailbreaks.