CVE-2026-42271

This is an authenticated RCE in LiteLLM's MCP (Model Context Protocol) preview endpoints. The vulnerability lives in the /mcp-rest/test/connection endpoint (and related preview paths), which accepts user-supplied MCP server configurations including the command, arguments, and environment variables for stdio-based subprocess spawning. An attacker with a valid LiteLLM API key can supply arbitrary commands in these fields and achieve immediate code execution on the host. The root cause is straightforward: the preview endpoints reuse the full stdio subprocess spawning mechanism without any authorization check. The developers apparently treated preview functionality as a low-risk testing utility, but the technical implementation spawns processes with the same privileges the production path would use. The stdio transport model itself is not vulnerable—it becomes exploitable when user-controlled config fields flow directly into subprocess spawning without scoping or validation. What makes this severe: the EPSS score of 0.83 indicates active exploitation in the wild, and it's now listed in CISA's KEV catalog. This means someone found, weaponized, and used it—likely against OpenShift AI deployments using LiteLLM as a proxy layer. Hardening steps: First, verify your LiteLLM version and confirm whether MCP preview endpoints are exposed to untrusted networks. Second, if you cannot patch immediately, restrict API key access to trusted users only—remember that any authenticated user can trigger this, not just admins. Third, the proper fix involves adding role-based authorization to any endpoint that spawns subprocesses based on user input, regardless of whether it's labeled 'preview' or 'test.' Fourth, consider whether your deployment model needs stdio transport at all—if you're not dynamically spawning MCP servers, disable that code path entirely. The deeper architectural question: preview endpoints that accept arbitrary subprocess configurations create an inherent tension between faithful testing and safe execution. A simulation layer that validates config syntax without spawning processes would eliminate this class of vulnerability, at the cost of not offering exact reproduction of production behavior. That trade-off is worth explicit engineering discussion.

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