LiteLLM and Kestra in KEV: exploited AI tooling is now a vulnerability management problem

CISA added fifteen CVEs to the Known Exploited Vulnerabilities catalog between 2 and 10 September, across five separate publication dates. Most are the usual edge: SonicWall, Fortinet, Citrix, Cisco, MikroTik, Chromium. Two are not.

CVE-2026-59822 is an improper authentication flaw in BerriAI LiteLLM, the open-source LLM gateway. CVE-2026-49869 is an unauthenticated OS command injection in Kestra OSS, a workflow orchestration engine. Both went in on 2 September, both with confirmed evidence of exploitation. Neither, in most organisations, appears in the asset inventory that feeds your scanner.

That is the part worth your attention. Not the tally.

What went in, and when

Verified against the CISA catalog feed, which listed 1,705 entries at its 10 September release. Due dates come from CISA and reflect Binding Operational Directive 26-04, which superseded BOD 22-01 on 10 June 2026 and replaced the old flat clock with a risk-based decision tree.

Two bugs that should worry you more than the appliances

Kestra: a suffix match where an exact match belonged

Kestra's authentication filter exempted the public configuration endpoint from Basic Auth using request.getPath().endsWith("/configs"). A suffix match, not an exact path match. Any API route whose final segment happens to be "configs" therefore skips authentication entirely. Kestra ships script execution plugins — shell, Python — enabled by default, so anyone who can create a workflow can run code. The result is unauthenticated remote code execution as root inside the worker container. CVSS 10.0, fixed in 1.0.45 and 1.3.21.

Microsoft observed the post-exploitation activity, according to reporting by The Hacker News: reverse shells, Docker socket enumeration, cryptocurrency miner deployment. Miners are the tell. Where commodity crews are mining, better-resourced crews have usually already had a look.

LiteLLM: an empty credential object instead of a rejection

LiteLLM's MCP Streamable HTTP endpoint carried an OAuth2 passthrough fallback. When validation of a LiteLLM API key failed, the handler instantiated an empty authentication object rather than terminating the request. Send any fabricated Bearer token and you get a working MCP session — able to list and call every MCP tool the gateway has configured, and to reach whatever those tools reach. GitLab's advisory database scores it 8.2. Fixed in 1.84.0.

This is the second time in three months LiteLLM has been the pivot. In June, Horizon3.ai published a chain joining CVE-2026-42271, a command injection in the MCP test endpoints, with CVE-2026-48710 — the Starlette Host header bug also added to KEV on 2 September. The Starlette flaw removed the authentication requirement; the LiteLLM flaw supplied the code execution. Horizon3.ai puts the affected LiteLLM range at 1.74.2 through 1.83.6, patched in 1.83.7, with Starlette fixed in 1.0.1.

Note what Starlette is. It is the ASGI framework underneath FastAPI, and so underneath a large share of the Python services your data and ML teams have shipped since 2023. A transitive dependency almost nobody tracks as an asset.

An LLM gateway is a credential concentrator. It holds provider API keys, virtual keys issued to internal teams, and increasingly the MCP connections that let a model reach your ticketing system, your repos and your cloud. Compromising it is not a lateral move. It is a shortcut past everything.

Why this tooling is invisible

Three reasons, and they compound.

It is installed by people who are not IT. A data scientist brings up a container and there is a gateway listening on port 4000. No change ticket, no CMDB record, no endpoint agent.

It is pinned, not patched. LiteLLM shipped dozens of releases between 1.74.2 and 1.84.0. Teams pin to whatever version worked when the pipeline last ran, and nothing pushes them forward on a cadence.

Its blast radius gets misjudged. A workflow orchestrator looks like internal plumbing. It is actually a machine that holds cloud credentials and executes arbitrary code on purpose — that is the product. The Kestra bug did not add a capability. It removed the login.

CISA's own deadlines make an argument worth arguing with

Look again at the due dates. Kestra, added 2 September, was due on the 5th. Three days. LiteLLM, added the same day, was due on the 16th. Fourteen.

BOD 26-04 weighs four variables: whether the asset is publicly exposed, whether the CVE is in KEV, whether exploitation is automatable, and whether the technical impact is partial or total control. LiteLLM's CVSS vector reads high confidentiality, low integrity, no availability. That does not score as total control of the asset, so it falls into the slower lane.

Defensible on the vector, wrong on the consequence. Reading every model configuration, provider key and virtual key out of a gateway is total control of everything downstream of it, even if the host itself stays untouched. Plenty of private-sector teams are copying BOD 26-04's tiering into their own SLAs. If you are one of them, do not let credential-holding systems inherit the fourteen-day tier because an integrity metric came out low.

Make KEV a feed, not a meeting

Five addition events in six working days breaks a weekly review. By the time Monday's call reaches the 2 September batch, three deadlines have already expired. Wire it in instead.

1. Poll https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json on a schedule. Hourly is not excessive; daily is the floor. Diff on cveID against your stored copy — the feed carries dateReleased and count fields, so detecting a refresh is cheap.
2. Join new CVEs against your SBOM, not only your scanner. Starlette and LiteLLM will never surface in an unauthenticated network scan. They surface in a lock file or a container image manifest.
3. Route unmatched CVEs to a human. An entry you cannot map to an asset is either genuinely irrelevant or a hole in your inventory, and you need to know which. Kestra and LiteLLM will land in that bucket for most teams on the first run.
4. Alert on vendor strings, not just CVE IDs. Put BerriAI, Kestra, Kludex and the rest of your AI stack on a watchlist that fires whether or not you believe you run them.
5. Carry CISA's dueDate into ticketing as the default SLA, then override upward where your own risk model says the tier is too generous. Automate the clock, keep judgement for the exceptions.
6. Sweep your external perimeter for the ports this tooling listens on — LiteLLM defaults to 4000, Kestra to 8080. Either one reachable from the internet is a finding in itself, patched or not.

One further thing about CVE-2026-59822 deserves flagging. The vulnerable surface is the MCP Streamable HTTP endpoint — a protocol that was not in production two years ago and now brokers tool access between models and internal systems at a growing number of organisations. The bug itself is dull: a failed check that returns an empty object where it should return an error. But the thing it guards is a new class of asset, deliberately wired to reach across trust boundaries, and CISA has now confirmed attackers are through it. Every MCP server you run is an authorisation boundary. Most of them were written quickly.