Your AI Gateway Is on the KEV Catalog Now

Run npm audit on the repo that calls the model and you'll get a clean sheet. Meanwhile, CISA's Known Exploited Vulnerabilities catalog just added three components that sit underneath that repo: LiteLLM, the open-source AI gateway; Starlette, the Python web framework under a large share of MCP servers; and Kestra, a workflow engine that increasingly wraps agent pipelines. All three on September 2. All three exploited in the wild before the catalog entry existed.

The gateway that authenticated nobody

LiteLLM sits between your application and whatever model providers you pay — one proxy, many keys, and increasingly the MCP endpoint that connects agents to tools. CVE-2026-59822 breaks that middle position. Before version 1.84.0, the MCP Streamable HTTP endpoint accepted a fabricated Authorization header, fell back to an OAuth2 passthrough path, and handed back an empty UserAPIKeyAuth() object — a session with no valid LiteLLM key behind it. CVSS 8.8. CISA added it to KEV on September 2 with a federal patch deadline of September 16.

That empty auth object is the whole bug. The endpoint asked "did this request authenticate?" and its fallback logic answered with an object that had no answer in it. Every downstream check then treated the request as done. An unauthenticated attacker doesn't just reach the MCP endpoint — they establish an authenticated MCP session, with whatever tools and credentials that session can touch.

Three components, one afternoon

The same KEV update carried two more entries you should read as a set:

• CVE-2026-48710 (Starlette, CVSS 6.5) — HTTP request/response smuggling that lets an attacker inject paths into the host part of the reconstructed URL. If any auth decision depends on that reconstructed path, it can be bypassed. CISA's entry notes it can be chained with LiteLLM's command injection bug. Starlette is the ASGI framework under a large fraction of self-hosted MCP servers, so this is not a corner case.
• CVE-2026-49869 (Kestra, unauthenticated command injection) — an unauthenticated remote attacker can create and execute arbitrary workflows without credentials. Federal agencies have until September 5 to patch it. That's two days after the KEV listing. CISA flags it for forensic triage — meaning they expect it running in environments worth breaching.

LiteLLM already had a second entry in the catalog: CVE-2026-42271, command injection in the MCP server preview endpoints, added in June. That one lets an authenticated user — including a low-privilege internal key — run arbitrary commands on the host. Reporting on the in-the-wild campaigns describes attackers submitting a fake MCP server configuration whose command field launched a Python downloader and a cryptominer.

Why your scans didn't flag any of this

Inventory tools enumerate what's declared: the app repo, the deployment manifest, the services with DNS names. The AI plumbing hides one layer down:

• The gateway is a proxy, not a product. It has no owner on the asset register, so nobody patches it on a deadline.
• MCP servers get stood up per-team, per-agent, sometimes per-hackathon. They multiply faster than anyone registers them.
• Workflow engines that look like internal tooling are, to an attacker, unauthenticated RCE with a friendly UI.

Wiz's 2026 cloud-AI report found 90% of cloud environments run self-hosted AI software and 63% host their own models. Lakera's audit of 10,000 public MCP servers found exploitable weaknesses on roughly 40% of hosts. The population is large and the hygiene is poor, and the KEV catalog just said the exploitation part out loud.

What to do this week

The boring steps, in the order that limits damage:

1. Upgrade LiteLLM to 1.84.0 or later — CVE-2026-59822 is fixed there. If you also run the MCP preview endpoints, get past 1.83.7-labs for CVE-2026-42271.
2. Rotate provider keys the proxy holds. Reporting on the campaigns found attackers pulling the proxy master key from process memory. Assume any long-lived key in a vulnerable gateway is burned, and rotate in a way that doesn't depend on the old key staying valid.
3. Find every LiteLLM, Starlette-based MCP server, and Kestra instance you run. Not the ones in the CMDB — the ones actually listening. Asset discovery beats the asset register here.
4. Put MCP endpoints behind an authenticated, network-restricted reverse proxy or take them off the network. An MCP server that answers initialize and tools/list to an anonymous caller is broadcasting its attack surface.
5. Watch for the tradecraft, not just the CVE. An AI server spawning shells, Python one-liners, Base64 decoders, archive extractors, or unexpected outbound DNS is either compromised or being probed. Both deserve a page.

What this doesn't cover

Patching LiteLLM closes these two CVEs, not the class. Any gateway, MCP server, or workflow engine that holds provider keys and accepts model-driven tool configs will keep producing bugs in this family — the preview-endpoint command injection and the Streamable HTTP bypass are cousins, not twins. Rotating keys helps only if you also fix how keys sit in memory and logs. And none of this addresses what a legitimate MCP session can do with over-scoped tools; auth is the floor, not the ceiling. The September 16 deadline is a floor too — treat it as the date your options run out, not the date the risk was born.

A gateway that never made the asset register just made the federal patch list. Your agents don't care which list it's on — they route through it either way.

Run the inventory today: every AI gateway, every MCP endpoint, every workflow engine. Three components made the KEV catalog in one afternoon. The fourth entry is the one you haven't found yet.

---

Further reading: how to probe an MCP server before you trust it, and the security checklist for MCP servers and system prompts — the five-minute handshake check that would have flagged most of these deployments before CISA did.