CVE-2026-40217

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.

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.

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.