Actively exploited in the wild
BerriAI LiteLLM SQL Injection Vulnerability
BerriAI - LiteLLM · Listed in the CISA KEV since 2026-05-08. This indicates confirmed attacks in production environments.
Required action: Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.
CVE-2026-42208
CriticalCVSS 9.8KEVExploitation Probability (EPSS)
Very high risk100th percentile - higher than 100% of all known CVEs
Summary
In LiteLLM versions from 1.81.16 to before 1.83.7, a database query used during proxy API key checks is vulnerable to SQL injection due to mixing caller-supplied key value into the query text. An unauthenticated attacker can send a crafted Authorization header to any LLM API route, leading to reading and potentially modifying data in the proxy's database.
Risk Assessment
An attacker could gain unauthorized access to the proxy and the credentials it manages, potentially leading to data leakage and system compromise.
Recommendation
Upgrade LiteLLM to version 1.83.7 or later, which contains a fix for the SQL injection vulnerability.
Other vulnerabilities in LiteLLM
See all- CVE-2026-37004Critical
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.
- CVE-2026-30623Critical
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.
- CVE-2026-59822HighActively exploited
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.
- CVE-2026-49468Critical
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.
- CVE-2026-42271HighActively exploited
LiteLLM versions 1.74.2 through 1.83.6 have a vulnerability in the POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list endpoints, which accept a full MCP server configuration including commands to execute. An authenticated user with any API key can run arbitrary commands on the proxy host.
- CVE-2026-40217High
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.
- CVE-2026-35030Critical
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.
- CVE-2026-35029High
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.
- CVE-2026-93355High
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.
- CVE-2026-89032High
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.
Original NVD description (English source)
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. From version 1.81.16 to before version 1.83.7, 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. This issue has been patched in version 1.83.7.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

