Patch LiteLLM CVE-2026-42271 Before Your AI Gateway Becomes a Shell

Confirmed: LiteLLM CVE-2026-42271 is a command-injection flaw in MCP server test endpoints that can run subprocesses on the AI gateway host. GitHub and NVD list the fixed LiteLLM version as 1.83.7, while CISA added the vulnerability to its Known Exploited Vulnerabilities catalog. Horizon3 separately reports that chaining it with Starlette CVE-2026-48710 can turn the issue into unauthenticated remote code execution on affected deployments.

What changed

LiteLLM versions 1.74.2 through 1.83.6 exposed two MCP preview endpoints: POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. Those endpoints accepted a full stdio server configuration, including command, args, and environment fields, then attempted to connect by spawning the supplied command.

The original issue required a valid LiteLLM proxy API key, but GitHub says the endpoints had no role check. The fix in LiteLLM 1.83.7 requires the PROXY_ADMIN role for those test endpoints, aligning them with the save endpoint.

Key takeaways

• Patch LiteLLM to 1.83.7 or later if you run a self-hosted AI gateway.
• Check Starlette as well; Horizon3 says Starlette 1.0.1 or later is needed to close the unauthenticated chain.
• Block /mcp-rest/test/connection and /mcp-rest/test/tools/list at the reverse proxy if you cannot patch immediately.
• Rotate provider keys and internal credentials stored on the proxy after suspected exposure.
• Review logs for unusual Host headers, MCP test endpoint calls, and unexpected subprocess execution.

Availability and access

This is not a product launch; it is an active patch window for teams that self-host LiteLLM or embed it in agent platforms. Hosted services may already have patched their infrastructure, but private deployments, containers, pinned Python environments, and copied compose files need direct verification.

Teams using LiteLLM as a central OpenAI-compatible proxy should treat it like a privileged control plane. It may hold provider keys, route traffic to internal tools, and sit close to MCP servers or agent sandboxes. That makes command execution on the proxy more serious than a bug in a disposable demo app.

Practical LinkLoot angle

Do not only bump the application dependency and move on. Inventory every place LiteLLM runs: developer sandboxes, staging proxies, agent runners, self-hosted gateway containers, and internal evaluation environments. AI infrastructure often spreads through experiments before security teams know it exists.

For agent stacks, add this to your operating checklist: gateway version, dependency tree, exposed endpoints, provider key scope, reverse-proxy rules, and subprocess execution logs. LinkLoot's AI workflow automation guide is a useful hub for keeping agent workflows practical without letting infrastructure sprawl hide risk.

What to verify before you act

• Confirm the running LiteLLM version, not just the version in a lockfile.
• Confirm Starlette is patched when LiteLLM is deployed with the vulnerable dependency path.
• Search ingress and app logs for calls to both MCP test endpoints.
• Rotate model-provider, cloud, database, and internal API credentials stored on the proxy if compromise is plausible.
• Limit who can create or test MCP stdio configurations in production.

Source check

Confirmed by: GitHub Advisory Database and NVD describe CVE-2026-42271, the affected LiteLLM range, the MCP test endpoints, the missing role check, and LiteLLM 1.83.7 as the fix. CISA lists CVE-2026-42271 in the Known Exploited Vulnerabilities catalog, which means defenders should treat it as exploited risk rather than backlog hygiene.

Independent context: Horizon3 reports a chain with Starlette CVE-2026-48710 that can bypass the original authentication requirement and reach unauthenticated RCE in affected deployments. Treat the chain as environment-dependent: verify your dependency tree and exposure before assuming either safety or compromise.