AI CVEs in CISA KEV: Ray, LiteLLM, and What's Missing

Every other vulnerability feed tells you what could be exploited. CISA’s Known Exploited Vulnerabilities catalog is the only widely used public list that claims something has been. That makes it the highest-signal feed available for prioritisation, and it makes its contents worth reading closely when your stack is machine learning infrastructure rather than the enterprise software KEV was built around.

Catalog version 2026.08.18 holds 1,670 entries. Three of them are AI-stack components: one Ray entry and two LiteLLM entries, all added in 2026. That number is small enough to read in full, and the shape of what made the list — and what conspicuously did not — says more about ML vulnerability management than the entries themselves.

What KEV membership actually means

An entry lands in KEV when CISA has evidence of active exploitation, the CVE has an assigned identifier, and there is a clear remediation action. For US federal civilian agencies it carries a binding remediation deadline. For everyone else it is not an obligation, but it is the strongest available public signal that a vulnerability has moved from theoretical to operational.

Two limits are worth keeping in front of you. KEV is scoped to what CISA can evidence and cares about defending, which skews toward products in federal environments. And exploitation evidence lags exploitation — an entry added today usually describes activity that started earlier. KEV is a floor on what is being exploited, never a ceiling.

Ray CVE-2025-62593: the dashboard attacks the developer

Added 17 August 2026, remediation due 20 August 2026 — a three-day window, which is how CISA signals urgency under its risk-based patching directive.

CVE-2025-62593 is a code-injection flaw in Ray prior to version 2.52.0, scored 9.4 under CVSS 4.0 and 8.8 under CVSS 3.1, with CWE-94 and CWE-352 assigned. The mechanism is the interesting part. Ray’s existing defence against browser-driven attacks checked whether the User-Agent header started with the string Mozilla. That is not a defence: the fetch specification permits the header to be modified, so the guard is bypassable from a page. Combine that bypass with a DNS rebinding attack and the target is not a server at all — it is a developer running Ray locally who visits a malicious website or is served a malicious advertisement. NVD lists a botnet infrastructure analysis among its references for the entry.

This inverts the threat model most teams apply to ML infrastructure. The assumption is that a Ray cluster is dangerous because it might be exposed to the internet. Here the cluster is on localhost, behaves correctly, and the attacker reaches it through the browser already running on the same machine. Network segmentation does not help. Only the upgrade to 2.52.0 does.

If your inventory has Ray anywhere — including on laptops, including in notebooks, including in a pip install ray a data scientist did last quarter — that is the entry to act on. The ML-stack CVE triage workflow covers how to turn a finding like this into a defensible decision rather than a panic patch, but for a KEV entry with a three-day federal deadline the decision is usually “upgrade”.

LiteLLM: two entries, one release

LiteLLM is an AI gateway — a proxy that fronts LLM APIs in OpenAI-compatible format and holds the provider credentials for everything behind it. Both of its KEV entries were fixed by the same release, v1.83.7.

CVE-2026-42208 — SQL injection, added to KEV 8 May 2026 with a three-day deadline, CVSS 9.8 (3.1) and 9.3 (4.0). From 1.81.16 to before 1.83.7, the database query used during proxy API key checks mixed the caller-supplied key value into the query text rather than passing it as a parameter. An unauthenticated attacker could send a crafted Authorization header to any LLM route — POST /chat/completions will do — and reach the query through the proxy’s error-handling path. Reading the proxy’s database means reading the credentials it manages.

CVE-2026-42271 — command injection, added 8 June 2026, CVSS 8.8 (3.1) and 8.7 (4.0). From 1.74.2 to before 1.83.7, two endpoints used to preview an MCP server before saving it accepted a full server configuration in the request body, including the command, args and env fields used by the stdio transport. Calling them with a stdio configuration spawned the supplied command. CISA’s summary is blunt about the privilege requirement: any authenticated user, “including holders of low-privilege internal-user keys”, could run arbitrary commands on the host.

Read together, these two describe the AI gateway’s real risk profile. It is simultaneously a credential vault holding every model provider key in the organisation and, because of MCP and tool integration, a component whose job description includes executing things. An unauthenticated SQLi in the first role and an authenticated command execution in the second are not unrelated bugs; they are the two halves of what a proxy in this position is for. Treat an AI gateway as a secrets-management system with an RCE surface bolted on, and patch it on that basis.

What is missing, and why that matters more

The most instructive absence in KEV is CVE-2023-48022 — the Ray jobs API remote code execution known as ShadowRay. It is not in the catalog.

That is not because it went unexploited. MITRE ATT&CK documents Campaign C0045 running from September 2023 to March 2024 against exposed Ray clusters, and characterises it as the first known case of AI workloads being actively exploited in the wild through AI infrastructure vulnerabilities. The GitHub advisory for it still shows an affected range up to 2.49.2 with no patched version, because the vendor’s position is that Ray is intended for a strictly controlled network environment and the jobs API behaving that way is by design.

That combination — exploited in the wild, disputed by the vendor, no patch, no clear remediation action — is exactly what KEV’s inclusion criteria cannot accommodate. There is no “apply the update” to require. So the single most consequential ML infrastructure exploitation campaign to date sits outside the one catalog most teams use as their exploitation signal.

The lesson generalises badly for anyone using KEV as an ML prioritisation feed. Three entries out of 1,670 does not mean the ML stack is safe. It means CISA’s evidence bar, federal scope and remediation-action requirement together filter out most of what goes wrong in this ecosystem: unpatchable-by-design behaviour, disputed advisories, artifact-level attacks with no CVE at all, and model-behaviour failures the CVE system does not model. The structural version of that argument is in ML model CVE tracking across your AI stack, and the artifact-layer blind spot is covered in malicious model file detection.

The adjacent entries worth knowing about

Two more KEV entries sit close enough to ML infrastructure to belong in the same inventory conversation.

The two LiteLLM entries also sit inside the LLM-orchestration CVE family this site tracks separately; the LangChain and LangGraph half of it is in LangChain security vulnerabilities.

CVE-2025-68613 (n8n), added 11 March 2026 — improper control of dynamically-managed code resources in a workflow automation platform that has become a common substrate for agent and LLM pipelines. If your ML orchestration runs through n8n, it is in scope even though nobody calls it an ML tool.

CVE-2020-11978 and CVE-2020-13927 (Apache Airflow), both added 18 January 2022 — command injection and an experimental-API authentication bypass. Airflow predates the current AI tooling wave but still schedules a large share of training and feature pipelines, and these two are the oldest reminder in the catalog that orchestration tools built for trusted internal networks get deployed on the open internet anyway.

That is the recurring pattern across every entry here. Ray, MLflow, LiteLLM, n8n and Airflow were all designed on the assumption of a trusted network and a trusted operator, and all of them ended up exposed, multi-tenant, or reachable from a browser. The vulnerability classes are unremarkable — SQLi, command injection, CSRF, missing auth. The delivery context is what makes them ML problems.

It is also the pattern to expect from the next additions. The inference runtimes have been accumulating unauthenticated-endpoint and memory-corruption entries at 9.0-and-above for two years without any of them reaching KEV yet — see inference server CVEs for that record. Absence from the catalog is a statement about confirmed exploitation evidence, not about exposure.

Using KEV without over-trusting it

• Map KEV against a real inventory, not a keyword. You need the list of ML components and versions you actually run before the catalog can tell you anything. Building that inventory is the prerequisite for every other control on this site.
• Subscribe to the catalog, not to summaries. The JSON feed updates on a published schedule and is small enough to diff on every run. Alert on any entry matching your inventory.
• Do not treat absence from KEV as absence of exploitation. ShadowRay is the proof case. Disputed and unpatched entries affecting your stack deserve a human read, not an automatic dismissal.
• Read the required action, not just the CVE. CISA’s entry text names the vendor advisory and the fixed version, which is frequently more specific than the NVD record at the time of listing.
• Pair it with the feeds that cover what KEV cannot. huntr for AI/ML disclosures at source, GitHub Security Advisories for patch state ahead of NVD enrichment, and MITRE ATLAS for adversary behaviour that will never be a CVE.

To check which of these entries touch the packages you run, alongside the rest of the published ML CVE record filtered by severity and fix availability, use the ML stack CVE filter.

See also

• Inference server CVEs: vLLM, Ollama, llama.cpp, Triton
• ML model CVE tracking across your AI stack
• MLflow CVEs: why 2.14.1 still fails your scanner
• How to triage an ML-stack CVE: a practical workflow
• trust_remote_code and the ML orchestration CVE class