CVE-2026-30623

This vulnerability in LiteLLM's MCP server creation endpoint deserves attention not because of its CVSS 9.8 score, but because of what it reveals about the security posture of LLM orchestration tools. The endpoint allows users to specify arbitrary commands and arguments that execute directly on the host. This is not a bug in input validation — it is a design failure where a tool positioned as an LLM API gateway was given the ability to spawn arbitrary system processes, a capability with no legitimate architectural justification. MCP (Model Context Protocol) is designed to extend an LLM's context through structured tool definitions and function calls. It should never require shell command execution. LiteLLM conflated 'extending LLM capabilities' with 'executing shell commands,' creating a direct path from API input to system compromise. A properly designed MCP server interface would register new tool endpoints or API integrations — not invoke exec(). The blast radius here is worse than a typical RCE. LiteLLM typically sits as a choke point holding credentials for every LLM provider it proxies. It mediates function calls that execute against internal systems. Compromising LiteLLM doesn't just give you one host — it gives you the keys to every downstream system and model endpoint it was trusted to access. If your deployment uses LiteLLM to manage agents with elevated permissions to modify code, approve transactions, or access sensitive data, the compromise chain extends well beyond the host. What to do now: First, disable MCP server creation entirely if you don't actively use it — unused features in orchestration tools are where vulnerabilities accumulate precisely because nobody watches them. Second, audit your LiteLLM deployment for any MCP server configurations that may have been created. Third, treat LiteLLM's security model as you would a secrets manager: the trust placed in it should be commensurate with its position in your architecture. Finally, expect the disclosure-to-patch gap to be the real exposure window — enterprise environments with change boards and deployment schedules will remain vulnerable long after a fix is available. Patch immediately, but plan for the organizational inertia that guarantees some population of instances will remain exposed.

Reviewed through automated stages and approved by a human before publication.