Litellm — CraftedSignal Threat Feed

LiteLLM Proxy API Key Verification SQL Injection

hello@craftedsignal.io — Fri, 08 Nov 2024 12:00:00 +0000

A critical SQL injection vulnerability has been identified in LiteLLM, specifically affecting versions 1.81.16 through 1.83.6. The vulnerability resides within the proxy API key verification process. Due to improper sanitization of the Authorization header, an unauthenticated attacker can inject arbitrary SQL commands. This is achieved by sending a specially crafted header to any LLM API route, such as POST /chat/completions, which triggers the vulnerable query through the proxy’s error-handling mechanism. Defenders should prioritize patching to version 1.83.7 or later to mitigate this risk, or implement the suggested workaround.

Attack Chain

The attacker sends a crafted HTTP Authorization header to a LiteLLM API endpoint (e.g., /chat/completions).
The LiteLLM proxy receives the request and extracts the API key from the Authorization header.
Due to insufficient sanitization, the API key value is directly concatenated into a SQL query string.
The vulnerable SQL query is executed against the proxy’s database.
The attacker injects SQL code to read sensitive data, such as user credentials or API keys, from the database.
The attacker may further inject SQL code to modify data, potentially granting themselves administrative privileges or compromising other users’ accounts.
The attacker gains unauthorized access to the LiteLLM proxy.
The attacker leverages the compromised proxy to access and control connected LLMs, exfiltrate data, or disrupt services.

Impact

Successful exploitation of this SQL injection vulnerability can lead to complete compromise of the LiteLLM proxy. Attackers could read or modify sensitive data within the proxy’s database, including API keys and credentials. This could lead to unauthorized access to managed LLMs and potentially allow attackers to exfiltrate sensitive data, disrupt services, or gain a foothold for further attacks within the compromised environment. The impact is significant due to the potential for widespread data breaches and service disruptions.

Recommendation

Upgrade LiteLLM to version 1.83.7 or later to patch the SQL injection vulnerability as detailed in the advisory GHSA-r75f-5x8p-qvmc.
If upgrading is not immediately feasible, set disable_error_logs: true in the general_settings configuration to mitigate the risk as described in the advisory GHSA-r75f-5x8p-qvmc.
Monitor web server logs for suspicious Authorization headers containing SQL injection payloads to detect potential exploitation attempts. Deploy the provided Sigma rule targeting HTTP request patterns.

LiteLLM Server-Side Template Injection Vulnerability

hello@craftedsignal.io — Tue, 05 Nov 2024 12:00:00 +0000

A server-side template injection (SSTI) vulnerability has been identified in LiteLLM versions 1.80.5 up to, but not including, 1.83.7. This flaw resides within the /prompts/test endpoint, which processes user-supplied prompt templates. Due to insufficient input sanitization, a malicious actor with a valid proxy API key can inject arbitrary code into the template, leading to its execution within the LiteLLM Proxy process. This vulnerability was disclosed on April 24, 2026. Successful exploitation can compromise the proxy’s environment, potentially exposing sensitive credentials like provider API keys and database passwords, or allowing arbitrary command execution on the host system. Organizations using affected versions of LiteLLM are at risk. The vulnerability is addressed in version 1.83.7-stable by implementing a sandboxed template renderer.

Attack Chain

An attacker authenticates to the LiteLLM proxy server using a valid API key.
The attacker crafts a malicious prompt template containing SSTI payloads.
The attacker sends a POST request to the /prompts/test endpoint, including the crafted template in the request body.
The LiteLLM proxy server receives the request and processes the template without proper sanitization.
The SSTI payload executes arbitrary code within the LiteLLM proxy process.
The attacker gains access to environment variables containing sensitive information, such as API keys and database credentials.
The attacker uses the exposed credentials to gain unauthorized access to external services or data.
The attacker executes arbitrary commands on the host system, potentially leading to full system compromise.

Impact

Successful exploitation of this SSTI vulnerability allows attackers to execute arbitrary code within the LiteLLM Proxy process. This can lead to the exposure of sensitive information such as API keys and database credentials, potentially enabling unauthorized access to other systems and data. Furthermore, attackers can execute arbitrary commands on the host, leading to full system compromise. The impact is significant for organizations relying on LiteLLM for managing and routing AI model requests, as it could result in data breaches, service disruption, and reputational damage.

Recommendation

Upgrade LiteLLM to version 1.83.7-stable or later to patch the vulnerability, as this version implements a sandboxed template renderer (see Patches).
As a temporary workaround, block POST /prompts/test at your reverse proxy or API gateway to prevent exploitation attempts (see Workarounds).
Review and rotate API keys that should not have access to prompt management routes to limit the potential impact of compromised keys (see Workarounds).
Deploy the Sigma rule “Detect LiteLLM SSTI Attempts via /prompts/test” to your SIEM to identify potential exploitation attempts based on HTTP request patterns.

LiteLLM Authenticated Command Execution via MCP stdio Test Endpoints

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

LiteLLM versions 1.74.2 through 1.83.6 are vulnerable to authenticated command execution. Two endpoints, POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list, intended for previewing MCP server configurations, allowed any authenticated user to execute arbitrary commands on the proxy host. This was possible because the endpoints accepted a full server configuration in the request body, including the command, args, and env fields used by the stdio transport, without proper role checks. An attacker could exploit this vulnerability by using a low-privilege API key to send a crafted request containing malicious commands, leading to command execution with the privileges of the proxy process. The vulnerability was patched in version 1.83.7 by enforcing the PROXY_ADMIN role for these endpoints.

Attack Chain

Attacker authenticates to the LiteLLM proxy with a valid, but low-privilege, API key.
Attacker crafts a malicious JSON payload containing a server configuration intended for the stdio transport. The payload includes the command, args, and env fields, which specify the command to be executed, its arguments, and environment variables, respectively.
Attacker sends a POST request to either the /mcp-rest/test/connection or /mcp-rest/test/tools/list endpoint, with the malicious JSON payload in the request body.
The LiteLLM proxy receives the request and, due to the vulnerability, attempts to connect to the supplied server configuration.
The proxy spawns the supplied command as a subprocess on the proxy host, using the privileges of the proxy process.
The attacker-supplied command executes arbitrary code on the host.
The attacker gains control of the proxy host with the privileges of the LiteLLM proxy.

Impact

Successful exploitation of this vulnerability allows an attacker to execute arbitrary commands on the host running the LiteLLM proxy. Since the vulnerability can be exploited with a low-privilege API key, this significantly broadens the attack surface. Depending on the privileges of the proxy process, this could lead to full system compromise, data exfiltration, or denial of service. The lack of specific victim count or sector targeting information in the advisory suggests a broad potential impact across various deployments of LiteLLM.

Recommendation

Upgrade LiteLLM to version 1.83.7 or later to remediate the vulnerability (see Patches).
As a temporary workaround, block POST requests to the /mcp-rest/test/connection and /mcp-rest/test/tools/list endpoints at your reverse proxy or API gateway (see Workarounds).
Monitor web server logs for POST requests to /mcp-rest/test/connection and /mcp-rest/test/tools/list endpoints, looking for suspicious command, args, and env parameters in the request body (see rules below).