Back to blog
CVEAI & LLMtechnical

LiteLLM CVE-2026-42271: command injection via MCP endpoints, actively exploited

Published on 2026-07-066 min readCleanIssue

> TL;DR: LiteLLM 1.74.2 through 1.83.6 lets any authenticated proxy user execute arbitrary commands on the server via two MCP test endpoints. CVSS 8.8, active exploitation confirmed by CISA on June 8, 2026. Fix: 1.83.7.

Why this concerns you

LiteLLM has become the standard plumbing for AI features in SaaS products: a single proxy that routes your calls to OpenAI, Anthropic, Mistral or self-hosted models, with key, quota and cost management. If your product added an AI assistant, a chat feature or LLM-based CV parsing in the last two years, there's a real chance a LiteLLM proxy is running somewhere in your infrastructure — sometimes installed by a contractor, sometimes inherited from a template.

It's exactly this kind of "invisible" building block that makes the best targets.

The flaw in two sentences

LiteLLM exposes endpoints to preview an MCP server before saving it: POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. These endpoints accepted a full server configuration in the request body — including the command, args and env fields used by the stdio transport.

In other words: you send a request with "command": "bash" and the arguments of your choice, and the proxy executes your command with its own privileges. No exotic deserialization, no complex exploit chain — the endpoint does exactly what it's told.

"Authenticated", so not a big deal?

Exploitation requires a proxy API key. Many teams stop at that word and file the flaw as minor. That's a misreading:

  • LiteLLM keys are often distributed widely internally (one per developer, one per service, one per environment);
  • they sit in .env files, Git histories and CI configurations;
  • a key meant to *call a model* here yields *code execution on the server* — a massive escalation between the privilege granted and the privilege obtained.
  • CISA added this CVE to its KEV catalog on June 8, 2026: it is being exploited in the wild, not in theory.

    What to do, in order

  • Check whether LiteLLM runs anywhere in your stack — including side projects, AI POCs that became production, and stacks set up by contractors. Red Hat OpenShift AI (2.25, 3.3, 3.4) also ships affected versions.
  • Upgrade to 1.83.7 or later — the fix restricts the configuration accepted by the test endpoints.
  • Rotate your proxy API keys — if the flaw could have been exploited, existing keys must be treated as compromised.
  • Hunt for traces: unusual processes spawned by the proxy, calls to /mcp-rest/test/* endpoints in your logs.
  • Isolate: an LLM proxy has no reason to run with broad privileges or on the same machine as your customer data.
  • The lesson beyond LiteLLM

    MCP surfaces are multiplying in AI products, and they arrive with a dangerous pattern: endpoints that accept *executable configurations* (command, arguments, environment) rather than data. Every time a request field ends up in a spawn(), you have an RCE candidate.

    If your SaaS wired up AI features quickly — assistant, RAG, document parsing — auditing that surface has become as urgent as auditing your classic APIs. Our First Review covers exposed AI and MCP endpoints: verdict in 48h.

    Related articles

    Three adjacent analyses to keep exploring the same attack surface.

    Sources

    Related services

    If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.

    Need an external review of your HR SaaS?

    Share your product, stack, and client context. We will come back with the right review scope.

    Discuss your audit