LiteLLM vulnerabilities

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 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.

A vulnerability has been found in BerriAI LiteLLM up to 1.94.0. This affects the function get_secret of the file secret_managers/main.py of the component Secret Resolution. The manipulation of the argument api_key leads to improper authorization. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A flaw has been found in BerriAI LiteLLM up to 1.95.0. Affected by this issue is the function ui_view_session_spend_logs of the file litellm/proxy/spend_tracking/spend_management_endpoints.py of the component Spend Tracking. Executing a manipulation of the argument session_id can lead to authorization bypass. It is possible to launch the attack remotely. The exploit has been published and may be used. Upgrading to version 1.96.0 can resolve this issue. This patch is called 722d9ffa4f6c5ae15702ab9ab2c5f6bf1688308b. The affected component should be upgraded.

LiteLLM contains a weak authentication vulnerability that allows an attacker holding a valid JWT from the configured identity provider to authenticate as any existing user by exploiting an email-based fallback lookup in the JWT authentication flow without verifying the email_verified claim. Attackers can present a token with an unverified email address matching a victim's account to inherit the victim's role, including proxy_admin privileges, and permanently overwrite the victim's stored identity binding to retain persistent unauthorized access to administrative endpoints exposing API keys and user management.

Vulnerability in BerriAI LiteLLM before 1.101.0-rc.1, allowing tenant isolation bypass in the semantic cache layer. Authenticated users can read other tenants' cached responses by exploiting a metadata key mismatch between _get_semantic_cache_tenant_scope() and _get_metadata_variable_name(). Attackers with a valid virtual key can submit semantically similar prompts to retrieve cached responses containing other tenants' PII, financial data, or source code, and can cause agentic front-ends to auto-execute attacker-supplied tool calls under victim credentials.

Prior to 1.83.9, an authenticated LiteLLM Proxy caller with a valid virtual key can place api_base inside the user_config request body to bypass is_request_body_safe, which blocks top-level api_base and base_url but previously did not inspect or reject user_config. Because user_config constructs the outbound router, the nested destination redirects a server-side request to an internal or external host selected by the caller.

In LiteLLM prior to versions 1.88.6 and 1.96.2, a vulnerability allowed any authenticated proxy user to redirect an outbound provider call to a destination the user controls and cause the proxy to send its configured provider credentials to that destination. Request validation in several files used incomplete checks that did not cover every sensitive parameter or inspect equivalent values across nested request fields, path values, and bracket-notation form data. Routing and credential parameters including api_base, base_url, model_list, fallbacks, and litellm_credential_name could therefore be applied without clearing the operator's stored key, exposing upstream provider credentials and other configured secrets and permitting server-side requests to internal services reachable by the proxy.

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.