LiteLLM CVE-2026-42271: Unauthenticated RCE Exploited in the Wild, Now on CISA KEV

CISA has added CVE-2026-42271 in BerriAI LiteLLM to its Known Exploited Vulnerabilities catalog, confirming active exploitation in the wild. The flaw is classified high-severity and chains to unauthenticated remote code execution — an attacker needs no credentials to run arbitrary commands on a vulnerable host.

Why This Matters

LiteLLM is one of the most widely deployed LLM proxy gateways in production AI infrastructure. Teams use it as a unified routing layer across OpenAI, Anthropic, Azure OpenAI, and dozens of other model providers. That central position makes a compromised instance extraordinarily dangerous: it sits inline with every model call your application makes, with direct access to provider API keys, prompt content, and response data.

Unauthenticated RCE on a network-reachable service is the worst possible outcome. There is no credential to steal first, no session to hijack, no prior access required. An attacker who can reach the LiteLLM port executes code immediately, as whatever user runs the process. In container or Kubernetes environments where LiteLLM is exposed on an internal service mesh — a very common deployment pattern — lateral movement to adjacent workloads becomes trivial.

The CISA KEV listing is not a theoretical warning. It means a working exploit chain is already in active use. Federal agencies face a binding remediation deadline under BOD 22-01. If you operate LiteLLM in any environment, you should treat this with the same urgency.

What to Do

1. Inventory immediately. Find every LiteLLM instance across your environment — containers, VMs, Kubernetes pods, local developer setups, internal tooling. Anything reachable over a network is in scope.

2. Patch now. Update to the latest LiteLLM release and redeploy. Confirm the patched version explicitly addresses CVE-2026-42271 in the changelog before marking remediation complete.

3. Restrict access in the interim. If you cannot patch within hours, firewall LiteLLM to accept connections only from explicitly trusted sources. It should never be directly internet-facing under any circumstances; if it is, take it offline until patched.

4. Rotate all provider API keys. If a vulnerable LiteLLM instance was network-accessible, treat every API key in its configuration as compromised. Rotate keys for every upstream provider — OpenAI, Anthropic, Azure, and any others — immediately after patching.

5. Review logs for indicators of compromise. Look for unexpected process executions, unusual outbound network connections, new files in writable directories, or anomalous request patterns in the period before your patch date. If you find anything suspicious, treat the host as compromised and escalate accordingly.

Active exploitation confirmed by CISA means working exploit code is circulating now. There is no grace period here.