CVE-2026-42271: LiteLLM Command Injection Is Confirmed Exploited in the Wild

According to the GitHub Security Advisory, two LiteLLM proxy endpoints, POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list, are designed to let an operator preview an MCP server configuration before adding it to the proxy. Both endpoints accept a full configuration object, including a stdio transport option that specifies a command to run. When a caller submits a stdio configuration, LiteLLM attempts to connect to it, and that connection attempt spawns the supplied command as a subprocess on the proxy host, running with the privileges of the proxy process itself.

The access control gap is what turns this into a real vulnerability rather than an administrative feature working as intended: any caller holding a valid LiteLLM proxy API key, not just an administrator, could reach these test endpoints and supply an arbitrary command. There is no command allowlist and no role gate restricting who can invoke the preview functionality. A low-privilege API key, the kind commonly issued to individual applications or teams calling the proxy, was enough to execute commands on the host.

A command injection bug is dangerous in any product. In a self-hosted LLM gateway like LiteLLM, the blast radius is unusually large for two structural reasons. First, LiteLLM proxies are typically deployed with wide network reach by design, since their job is to sit in front of every internal application and route model calls outward to multiple providers. A command executed on that host can pivot into whatever internal network segment the proxy was placed to serve. Second, the proxy holds the API credentials for every connected model provider, meaning a successful command injection does not just compromise a single application, it can expose the organization's entire AI provider credential set in one step. For organizations that have centralized their AI infrastructure around a single gateway, as many have done specifically to simplify credential management, that centralization becomes the single point of failure once the gateway itself is compromised. Our earlier coverage of securing agentic AI in the enterprise covers this same centralization tradeoff in more detail.

LiteLLM versions 1.74.2 through 1.83.6 are affected, per the GitHub Security Advisory. BerriAI fixed the issue in version 1.83.7, released alongside the advisory. Organizations running any self-hosted LiteLLM proxy in that version range should treat this as an immediate upgrade candidate rather than a routine patch cycle item, given the confirmed exploitation status covered below. If you are running a fork, a vendor-repackaged build, or cannot confirm your exact deployed version against the GitHub release history, verify directly against BerriAI's repository rather than assuming the version range above is exhaustive for your environment.

CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities catalog on June 8, 2026, citing evidence of active exploitation. This platform's threat intelligence library corroborates that status from the CISA KEV catalog as its single source for this entry, so treat the exploitation confirmation as coming from CISA specifically rather than from multiple independently corroborating outlets. At the time of KEV addition, there was no public information identifying the threat actor or actors behind the exploitation, how widespread the activity is, or whether any specific organization's LiteLLM deployment has been confirmed compromised. Be cautious of any secondary reporting that names a specific campaign or group for this CVE without citing a primary source, since the record as of this writing does not support that level of attribution.

What is well documented is a severity escalation path. Researchers at Horizon3.ai demonstrated that CVE-2026-42271 can be chained with CVE-2026-48710, a Host header authentication bypass in the Starlette web framework (nicknamed BadHost) affecting LiteLLM deployments whose dependency tree includes vulnerable Starlette versions. Chained together, the two flaws bypass LiteLLM's authentication entirely and convert the command injection into unauthenticated remote code execution reachable from any network-connected host, with a combined CVSS score of 10.0. Any exposure assessment for CVE-2026-42271 should also check whether the deployment's Starlette dependency is vulnerable to CVE-2026-48710, since the standalone CVSS 8.8 score for CVE-2026-42271 alone understates risk for any deployment where both conditions are present.

Our platform maintains detection content specific to CVE-2026-42271's MCP test-endpoint command injection pattern, translated into vendor-specific variants for Splunk, Elastic, Microsoft Sentinel and Defender, CrowdStrike, SentinelOne, Cortex XDR, QRadar, and Chronicle, alongside the underlying Sigma rule and retrospective hunt queries covering the same pattern. Treat this content as system-drafted and unvalidated against a confirmed exploit sample, not a vendor-verified signature, and adapt field names to your own proxy's actual logging configuration before relying on it operationally. The general guidance below covers the same detection categories in plain terms for teams building this out manually:

Before patching, confirm whether your deployment is actually reachable and exploitable. Identify every LiteLLM proxy instance in your environment and record its exact running version against the 1.74.2 through 1.83.6 affected range. Confirm whether the MCP test endpoints are reachable by any API key holder, not only administrators, since the access control gap is what makes this exploitable by low-privilege callers. Separately verify your Starlette dependency version against CVE-2026-48710 to determine whether the unauthenticated RCE chain applies to your specific deployment. After patching, review historical access logs covering the period before the advisory's publication date for any of the request patterns described in the detection guidance above, since upgrading closes the vulnerability going forward but does not retroactively tell you whether it was already exploited against your environment.

This platform's persisted Respond actions for CVE-2026-42271 give the concrete remediation sequence, grounded in the confirmed exploitation status and the vendor's own fix:

If your LiteLLM deployment is a fork, a repackaged build, or anything you can't cleanly map to the 1.74.2 through 1.83.6 range, don't rely on the version numbers in this article to clear yourself: check directly against BerriAI's GitHub repository and security advisory, since a downstream fork can lag or diverge from upstream version numbering. The vendor-specific detection content above is system-drafted, not independently vetted against a confirmed exploit sample; if you already run a SIEM correlation rule tuned to MCP test-endpoint traffic, prioritize reviewing that over the platform-native content. Exploitation confirmation traces to CISA's KEV catalog alone in this platform's data, and no threat actor, campaign, or affected-organization count has been published, so hold off on naming one in your own incident documentation until a primary source confirms it. Given how much access a LiteLLM proxy typically holds, every connected provider's API credentials and broad network reach, a version-mapping gap here is a reason to isolate the host now rather than wait for certainty, not a reason to deprioritize it. Readers evaluating build pipeline exposure more broadly may also find our piece on detecting supply chain compromise in software build pipelines useful context for the AI infrastructure layer this vulnerability sits in.