LiteLLM versions from 1.87.0 up to but not including 1.100.4, and certain subsequent minor versions, contain an improper privilege management vulnerability. The proxy server reuses a cryptographic context for secrets and session tokens, enabling an authenticated internal user to forge administrator credentials. This allows escalation to administrative access and execution of arbitrary commands via the MCP stdio endpoint. Early vulnerable versions require an experimental login feature enabled, while later versions are exploitable by default. The issue is fixed in versions 1.100.4, 1.101.3, 1.102.2, 1.103.1, and 1.104.0-rc.2.
A vulnerability exists in BerriAI LiteLLM versions up to 1.94.0 in the get_secret function of secret_managers/main.py. This flaw involves improper authorization due to manipulation of the api_key argument, allowing remote attackers to exploit it. The vulnerability has a CVSS score of 6.3, indicating a moderate impact on confidentiality, integrity, and availability. The vendor was notified but has not responded, and no patch or mitigation guidance is currently available. Public exploit details have been disclosed, but no known exploitation in the wild has been reported.
A vulnerability in BerriAI LiteLLM up to version 1.95.0 allows remote attackers to bypass authorization by manipulating the session_id argument in the ui_view_session_spend_logs function of the Spend Tracking component. This issue is resolved by upgrading to version 1.96.0.
LiteLLM in BerriAI has a weak authentication vulnerability that allows attackers with a valid JWT to impersonate any user by exploiting an email-based fallback lookup that does not verify the email_verified claim. This flaw enables attackers to inherit victim roles, including administrative privileges, and persistently overwrite identity bindings to maintain unauthorized access to sensitive endpoints.
BerriAI LiteLLM before 1.101.0-rc.1 contains a tenant isolation bypass vulnerability in the semantic cache layer that allows authenticated users to read other tenants' cached responses by exploiting a metadata key mismatch between _get_semantic_cache_tenant_scope() and _get_metadata_variable_name(). Attackers holding a valid virtual key can submit semantically similar prompts on affected routes such as /v1/responses and /bedrock/* to retrieve cached responses containing other tenants' personally identifiable information, financial data, or source code, and can cause agentic front-ends to auto-execute attacker-supplied tool calls under victim credentials by returning cached function_call or tool_calls payloads to a different principal.
CVE-2026-59823 is a Server-Side Request Forgery (SSRF) vulnerability in BerriAI's LiteLLM proxy server versions prior to 1.83.9. An authenticated user with a valid virtual key could exploit this flaw by placing an api_base parameter inside the user_config request body, bypassing existing safety checks. This allows the attacker to redirect server-side requests to internal or external hosts not normally accessible, potentially exposing sensitive endpoints. The issue is resolved in version 1.83.9.
LiteLLM version 1.18.10 contains a critical remote code execution vulnerability in its MCP server creation functionality. The vulnerability arises because the application executes arbitrary commands and arguments specified in a JSON configuration without validation. This allows an attacker to run operating system commands with the privileges of the LiteLLM process. The vulnerability has a CVSS score of 9.8, indicating a critical severity level. No patch or official remediation has been confirmed at this time.
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.10-stable, LiteLLM's /health/test_connection endpoint resolved request-supplied environment and OIDC file references in litellm_params, allowing a proxy administrator or another privileged caller with permission to test model connections to read files from the local filesystem via an oidc/file/ reference. This issue is fixed in version 1.83.10-stable.
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.84.0, LiteLLM's MCP Streamable HTTP endpoint allowed an unauthenticated attacker to use a fabricated Authorization header to trigger an OAuth2 passthrough fallback path that replaced failed LiteLLM key validation with an empty UserAPIKeyAuth() object, allowing requests to reach MCP tooling without a valid LiteLLM key. This issue is fixed in version 1.84.0.
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.7-stable, LiteLLM Skills archive extraction did not sufficiently validate file paths from uploaded skill ZIP archives, allowing an authenticated user with access to LiteLLM LLM API routes or a key whose allowed_routes includes /v1/skills, anthropic_routes, or llm_api_routes to upload a crafted skill archive containing path traversal entries that could be written outside the intended extraction or staging directory. This issue is fixed in version 1.83.7-stable.
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.82.0-stable, LiteLLM's Custom Code Guardrails production create and update paths did not apply the same sandboxing and validation used by the test endpoint, allowing a privileged user with access to create or update guardrails to submit custom Python code that executed in the LiteLLM proxy environment and could expose secrets available to the process. This issue is fixed in version 1.82.0-stable.
LiteLLM prior to 1.83.10 allows a user to modify their own user_role via the /user/update endpoint. While the endpoint correctly restricts users to updating only their own account, it does not restrict which fields may be changed. A user who can reach this endpoint can set their role to proxy_admin, gaining full administrative access to LiteLLM including all users, teams, keys, models, and prompt history. Users with the org_admin role have legitimate access to this endpoint and can exploit this vulnerability without chaining any additional flaw.
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. When generating a key, the allowed_routes field is stored without verifying that the specified routes fall within the user's own permissions. A key created with access to admin-only routes can then be used to reach those routes successfully, bypassing the role-based access controls that would otherwise block the request, enabling full privilege escalation from internal_user to proxy_admin.
### Impact
A database query used during proxy API key checks mixed the caller-supplied key value into the query text instead of passing it as a separate parameter. An unauthenticated attacker could send a specially crafted `Authorization` header to any LLM API route (for example `POST /chat/completions`) and reach this query through the proxy's error-handling path.
An attacker could read data from the proxy's database and may be able to modify it, leading to unauthorised access to the proxy and the credentials it manages.
### Patches
Fixed in **`1.83.7`**. The caller-supplied value is now always passed to the database as a separate parameter. Upgrade to `1.83.7` or later.
### Workarounds
If upgrading is not immediately possible, set `disable_error_logs: true` under `general_settings`. This removes the path through which unauthenticated input reaches the vulnerable query.
### References
- Patched release: [`v1.83.7-stable`](https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable)
**Discovery Credit**: Tencent YunDing Security Lab
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. From version 1.80.5 to before version 1.83.7, the POST /prompts/test endpoint accepted user-supplied prompt templates and rendered them without sandboxing. A crafted template could run arbitrary code inside the LiteLLM Proxy process. The endpoint only checks that the caller presents a valid proxy API key, so any authenticated user could reach it. Depending on how the proxy is deployed, this could expose secrets in the process environment (such as provider API keys or database credentials) and allow commands to be run on the host. This issue has been patched in version 1.83.7.
CVE-2026-42271 is a command injection vulnerability in BerriAI's LiteLLM proxy server versions 1.74.2 up to but not including 1.83.7. Two endpoints allowed authenticated users, including those with low-privilege API keys, to execute arbitrary commands on the proxy host by submitting crafted server configurations. This flaw arises from insufficient role checks and improper neutralization of command execution parameters. The vulnerability has been patched in version 1.83.7.
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.0, when JWT authentication is enabled (enable_jwt_auth: true), the OIDC userinfo cache uses token[:20] as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters. This configuration option is not enabled by default. Most instances are not affected. An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user's cached token. On cache hit, the attacker inherits the legitimate user's identity and permissions. This affects deployments with JWT/OIDC authentication enabled. Fixed in v1.83.0.
CVE-2026-35029 is a high-severity vulnerability in LiteLLM, an AI Gateway proxy server. Prior to version 1.83.0, the /config/update endpoint lacks proper admin role authorization, allowing any authenticated user to modify proxy configurations and environment variables. This can lead to remote code execution, unauthorized reading of server files, and takeover of privileged accounts. The issue is fixed in LiteLLM version 1.83.0.
SQL Injection vulnerability in BerriAI LiteLLM before 1.81.0 allows attackers to execute arbitrary commands via the key parameter to the "/key/block" and "/key/unblock" API endpoints.