LiteLLM vulnerabilities

LiteLLM 1.18.10 contains a remote code execution vulnerability in its MCP server creation functionality. The application allows users to add MCP servers via a JSON configuration specifying arbitrary command and args values, which are executed on the host without validation. This enables attackers to run arbitrary operating system commands.

LiteLLM proxy before version 1.84.0 has a Host-header parsing flaw that, under specific conditions, allows unauthenticated access to protected management routes. The issue arises from a mismatch between the route evaluated by the auth layer and the route actually dispatched by FastAPI.

A vulnerability in LiteLLM through 2026-04-08 allows remote attackers to execute arbitrary code via bytecode rewriting at the /guardrails/test_custom_code URI.

In LiteLLM prior to 1.83.0, when JWT authentication is enabled (enable_jwt_auth: true), the OIDC userinfo cache uses the first 20 characters of the token as the cache key. JWT tokens produced by the same signing algorithm have identical first 20 characters, allowing an unauthenticated attacker to craft a token matching the cache and inherit a legitimate user's identity and permissions.

LiteLLM before version 1.83.0 has a vulnerability where the /config/update endpoint does not enforce admin role authorization. An authenticated user can modify proxy configuration, environment variables, and register custom pass-through endpoint handlers, leading to remote code execution, arbitrary file reading, and takeover of privileged accounts.

BerriAI litellm <=1.82.4 is vulnerable to Server-Side Template Injection (SSTI), allowing unauthenticated remote attackers to execute arbitrary OS commands via a crafted dotprompt_content parameter in the /prompts/test endpoint due to use of an unsandboxed jinja2.Environment.

LiteLLM before version 1.84.0 has a vulnerability in the MCP Streamable HTTP endpoint that allows an unauthenticated attacker to bypass LiteLLM key validation using a crafted Authorization header. The attacker can exploit the OAuth2 passthrough fallback path to replace failed key validation with an empty UserAPIKeyAuth() object, allowing requests to reach MCP tooling without a valid key.

LiteLLM prior to version 1.82.0-stable did not apply proper sandboxing and validation for Custom Code Guardrails during creation and update, allowing a privileged user to execute arbitrary Python code in the proxy environment and potentially expose process secrets.

LiteLLM before version 1.83.7-stable has a vulnerability due to insufficient file path validation when extracting Skills ZIP archives. An authenticated user with access to LLM API routes or a key with /v1/skills, anthropic_routes, or llm_api_routes can upload a crafted archive that writes files outside the intended directory (path traversal).

LiteLLM before version 1.83.10-stable has a vulnerability in the /health/test_connection endpoint that allows reading files from the local filesystem via oidc/file/ references. The flaw is due to the server resolving request-supplied environment and OIDC file references in litellm_params.

LiteLLM prior to version 1.83.10 allows a user to modify their own role via the /user/update endpoint. The endpoint restricts access to the user's own account but does not validate which fields can be changed. A user can set their role to proxy_admin, gaining full administrative access to all users, teams, keys, models, and prompt history.

LiteLLM prior to 1.83.14 allows an authenticated internal_user to create API keys with access to routes that their role does not permit. The allowed_routes field is stored without verifying that the specified routes fall within the user's own permissions, enabling privilege escalation to proxy_admin.

LiteLLM versions 1.80.5 through 1.83.7 have a vulnerability in the POST /prompts/test endpoint that accepts user-supplied prompt templates and renders them without sandboxing. A crafted template can execute arbitrary code within the LiteLLM Proxy process.