Vulnerabilities

BerriAI LiteLLM, a widely used self-hosted AI gateway and proxy server for calling LLM APIs, fails to properly authenticate requests to its MCP Streamable HTTP endpoint in versions prior to 1.84.0. An unauthenticated attacker can send a fabricated Authorization header that triggers an OAuth2 passthrough fallback, which replaces failed LiteLLM key validation with an empty UserAPIKeyAuth() object and lets the request reach MCP tooling without any valid LiteLLM key. Successful exploitation grants unauthenticated access to the gateway's MCP tooling with high confidentiality impact per the CVSS 4.0 score of 8.8, and public reporting describes attackers chaining LiteLLM weaknesses from authentication bypass to root code execution and cloud credential theft. Any organization running LiteLLM before 1.84.0 is affected, particularly gateways exposed to the internet. The flaw is confirmed exploited in the wild: CISA added it to the Known Exploited Vulnerabilities catalog on 2026-09-02, while EPSS currently estimates a 0.9% probability of exploitation in the next 30 days.

Do: Upgrade LiteLLM to version 1.84.0 or later immediately, in line with the CISA KEV required action and BOD 26-04 guidance for internet-exposed assets. Audit whether the MCP endpoint is reachable from the internet and check for signs of exploitation, including unexpected MCP tool calls, use of fabricated Authorization headers, and use of default or example admin keys such as 'sk-1234'. Until patched, restrict access to the MCP endpoint and review cloud credentials accessible from the gateway host for signs of theft or root-level activity.

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.84.0, a Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes. The auth layer derived the effective route from request.url.path in litellm/proxy/auth/auth_utils.py::get_request_route(), which Starlette reconstructs from the Host header. A crafted Host could therefore make the auth gate evaluate a different route from the one FastAPI dispatched. This vulnerability is fixed in 1.84.0.

A weakness has been identified in BerriAI litellm up to 1.59.8. Affected is the function UserAPIKeyAuth of the file litellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py of the component MCP Proxy. Executing a manipulation can lead to improper authentication. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure.

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.

BerriAI LiteLLM, an open-source proxy server (AI gateway) used to call LLM APIs in OpenAI or native format, contains a SQL injection (CWE-89) in the database query performed during proxy API key checks in versions 1.81.16 through before 1.83.7: the caller-supplied key value was mixed into the query text rather than passed as a parameter. An unauthenticated attacker triggers the flaw by sending a specially crafted Authorization header to any LLM API route (for example POST /chat/completions), reaching the vulnerable query through the proxy's error-handling path. Successful exploitation lets the attacker read data from the proxy's database and potentially modify it, leading to unauthorized access to the proxy and the API keys/credentials it manages; CVSS 4.0 rates it 9.3 (critical). Any organization running an affected LiteLLM proxy version is affected, particularly instances reachable over a network. Exploitation is confirmed in the wild: the flaw was reportedly exploited within 36 hours of disclosure, CISA added it to the Known Exploited Vulnerabilities catalog on 2026-05-08, and EPSS puts the 30-day exploitation probability at 89.4%.

Do: Upgrade LiteLLM to version 1.83.7 or later immediately; exploitation began within 36 hours of disclosure, the flaw is in CISA's KEV catalog, and federal agencies must apply mitigations under BOD 22-01. Until patched, restrict network access to the proxy, and review proxy database logs for unexpected queries or unauthorized key usage; if compromise is suspected, rotate the API keys and credentials stored in the proxy database. Also check your exposure to the separately reported LiteLLM issue CVE-2026-42271, which is reported as exploited in the wild and chains to unauthenticated RCE.

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.

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

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-33634 is an embedded malicious code (supply chain) vulnerability in which a threat actor using compromised Aquasecurity credentials published a backdoored Trivy v0.69.4 release on March 19, 2026, force-pushed 76 of 77 version tags in the aquasecurity/trivy-action GitHub Action to credential-stealing malware, and replaced all 7 tags in aquasecurity/setup-trivy with malicious commits. The malicious code executes when CI/CD pipelines pull or run the affected Trivy Go module/container image or when workflows resolve the compromised mutable version tags, including runs on March 19-20, 2026 that referenced tags instead of pinned commit SHAs. An attacker gains code execution in developer CI environments and can steal secrets (cloud, registry, and other credentials accessible to affected pipelines), with a repository named 'tpcp-docs' appearing in an organization indicating the fallback exfiltration mechanism fired and secrets were taken. Anyone who pulled or executed Trivy 0.69.4 or referenced affected trivy-action (0.0.1-0.34.2) or setup-trivy (0.2.0-0.2.6) tags is affected, and related malicious LiteLLM releases tied to the same campaign may have exposed 2,100+ organizations. Exploitation is confirmed in the wild: CISA added the flaw to its Known Exploited Vulnerabilities catalog on March 26, 2026, EPSS estimates a 59.2% probability of exploitation within 30 days, and the FBI reports the TeamPCP actor compromised developer tools to steal cloud credentials.

Do: Move to known-safe releases - Trivy 0.69.2/0.69.3 (avoiding 0.69.4), trivy-action 0.35.0, and setup-trivy 0.2.6 as recreated with a safe commit - and remove any pulled or executed Trivy 0.69.4 artifacts. Treat all secrets accessible to affected pipelines as exposed and rotate them immediately; check workflow run logs from March 19-20, 2026 for tag-referencing workflows, look for a 'tpcp-docs' repository in your GitHub organization as an exfiltration indicator, and pin all GitHub Actions to full, immutable commit SHAs. Per the CISA KEV required action, apply vendor mitigations or follow applicable BOD 22-01 guidance for cloud services.

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.

BerriAI/litellm version 1.40.12 contains a vulnerability that allows remote code execution. The issue exists in the handling of the 'post_call_rules' configuration, where a callback function can be added. The provided value is split at the final '.' mark, with the last part considered the function name and the remaining part appended with the '.py' extension and imported. This allows an attacker to set a system method, such as 'os.system', as a callback, enabling the execution of arbitrary commands when a chat response is processed.

CVE-2024-6587 is a server-side request forgery (SSRF, CWE-918) flaw in the BerriAI LiteLLM LLM proxy, reported for version 1.38.10. It is triggered when a client supplies an attacker-controlled `api_base` parameter in a request to POST /chat/completions, causing LiteLLM to send that request — including the configured OpenAI API key — to the attacker-chosen domain. An attacker who points `api_base` at a server they control can intercept the OpenAI API key and then access or misuse it directly against the OpenAI API, giving a high-confidentiality impact per the 7.5 CVSS score (no integrity or availability impact). Any deployment of LiteLLM that allows callers, without authentication per the CVSS vector (PR:N), to set `api_base` on this endpoint is affected, with internet-exposed proxy instances at greatest risk. No confirmed in-the-wild exploitation of this specific CVE is documented yet, but a public proof-of-concept exists, EPSS assigns a ~35% (98th-percentile) probability of exploitation within 30 days, and defenders are reporting a broader coordinated surge in SSRF exploitation.

Do: Upgrade LiteLLM to the latest patched release and stop trusting client-supplied `api_base` values — validate or allow-list them, or disable user-controlled `api_base` on /chat/completions. Review proxy logs for completions requests sent to unexpected external domains and rotate any OpenAI API keys configured in LiteLLM, since a leaked key gives attackers direct access to your OpenAI account and billing.

BerriAI/litellm version v1.35.8 contains a vulnerability where an attacker can achieve remote code execution. The vulnerability exists in the `add_deployment` function, which decodes and decrypts environment variables from base64 and assigns them to `os.environ`. An attacker can exploit this by sending a malicious payload to the `/config/update` endpoint, which is then processed and executed by the server when the `get_secret` function is triggered. This requires the server to use Google KMS and a database to store a model.

BerriAI's litellm, in its latest version, is vulnerable to arbitrary file deletion due to improper input validation on the `/audio/transcriptions` endpoint. An attacker can exploit this vulnerability by sending a specially crafted request that includes a file path to the server, which then deletes the specified file without proper authorization or validation. This vulnerability is present in the code where `os.remove(file.filename)` is used to delete a file, allowing any user to delete critical files on the server such as SSH keys, SQLite databases, or configuration files.

BerriAI/litellm is vulnerable to Server-Side Template Injection (SSTI) via the `/completions` endpoint. The vulnerability arises from the `hf_chat_template` method processing the `chat_template` parameter from the `tokenizer_config.json` file through the Jinja template engine without proper sanitization. Attackers can exploit this by crafting malicious `tokenizer_config.json` files that execute arbitrary code on the server.