Attack Chain

1. An attacker identifies a LiteLLM instance running a vulnerable version (<= 2026-04-08) with the /guardrails/test_custom_code endpoint exposed.
2. The attacker crafts a malicious HTTP request targeting the /guardrails/test_custom_code URI.
3. The malicious request includes specially crafted data designed to rewrite the bytecode executed by the LiteLLM instance.
4. The LiteLLM application, due to the vulnerability, processes the attacker-supplied data without proper sanitization or validation.
5. The application rewrites its own bytecode based on the attacker’s input.
6. The rewritten bytecode contains malicious code injected by the attacker.
7. The application executes the rewritten bytecode, effectively executing the attacker’s injected code.
8. The attacker gains arbitrary code execution on the server, allowing them to compromise the system, install malware, or exfiltrate data.

Impact

Successful exploitation of CVE-2026-40217 allows unauthenticated remote attackers to execute arbitrary code on systems running vulnerable versions of LiteLLM. This can lead to complete system compromise, including data theft, ransomware deployment, and denial of service. The vulnerability could affect any organization utilizing LiteLLM for LLM interaction, particularly those exposing the vulnerable endpoint to untrusted networks. The impact is rated as critical due to the ease of exploitation and the potential for widespread damage.

Recommendation

• Apply the necessary patches or upgrade to a version of LiteLLM that addresses CVE-2026-40217 immediately.
• Implement network segmentation to restrict access to the /guardrails/test_custom_code endpoint, as referenced in the vulnerability description.
• Deploy the provided Sigma rule Detect LiteLLM Bytecode Rewrite Attempt to identify potential exploitation attempts targeting the vulnerable endpoint.
• Monitor web server logs for suspicious POST requests to the /guardrails/test_custom_code URI, using the log source specified in the Sigma rule.

Attack Chain

1. Attacker gains initial access to LiteLLM and authenticates as a low-privilege user.
2. Attacker sends a request to /user/info to retrieve the password hash of another user.
3. The API responds with the target user’s SHA-256 password hash.
4. Attacker sends a POST request to the /v2/login endpoint using the stolen SHA-256 hash as the password.
5. The /v2/login endpoint accepts the raw SHA-256 hash without re-hashing.
6. The server authenticates the attacker as the target user.
7. Attacker now has the privileges of the target user, potentially gaining access to sensitive data or administrative functions.

Impact

Successful exploitation of this vulnerability leads to unauthorized access and privilege escalation within the LiteLLM application. An attacker can impersonate other users, including administrators, potentially leading to data breaches, system compromise, and unauthorized modifications. The number of victims depends on the deployment size, but any LiteLLM instance running a version prior to 1.83.0 is vulnerable. Sectors utilizing LiteLLM are at risk.

Recommendation

• Upgrade LiteLLM to version 1.83.0 or later to patch the vulnerability (reference: Patches section).
• Deploy the Sigma rule “Detect LiteLLM User Info Hash Access” to monitor for unauthorized access to user password hashes via the /user/info endpoint (reference: rule: “Detect LiteLLM User Info Hash Access”).
• Deploy the Sigma rule “Detect LiteLLM Login with SHA256 Hash” to detect login attempts using SHA256 hashes (reference: rule: “Detect LiteLLM Login with SHA256 Hash”).

Attack Chain

While the specifics of the attack chain are not fully detailed in the source, a typical supply chain attack targeting PyPI packages involves the following steps:

1. Package Compromise: Threat actor gains unauthorized access to the Litellm PyPI account or the build environment.
2. Malicious Code Injection: The attacker injects malicious code into the setup.py or other relevant files within the Litellm package. This malicious code could be designed to execute upon installation.
3. Version Release: The compromised versions, 1.82.7 and 1.82.8, are released to PyPI, making them available for users to download and install.
4. Package Installation: Users unknowingly download and install the compromised Litellm package using pip, triggering the execution of the injected malicious code.
5. Initial Access: The malicious code may establish a reverse shell, download additional payloads, or perform other actions to gain initial access to the victim’s system.
6. Persistence: The attacker may establish persistence on the compromised system through various techniques, such as creating scheduled tasks or modifying startup scripts.
7. Data Exfiltration/Malware Deployment: Depending on the attacker’s objective, they may exfiltrate sensitive data, deploy ransomware, or perform other malicious activities.
8. Lateral Movement: The attacker may attempt to move laterally to other systems within the compromised network, escalating their access and expanding their reach.

Impact

The compromise of Litellm versions 1.82.7 and 1.82.8 could lead to widespread compromise of systems that use the package. The injected malicious code could enable attackers to steal sensitive information, deploy malware, or gain unauthorized access to victim systems. The number of affected users is estimated to be in the thousands. This incident highlights the risks associated with supply chain attacks targeting open-source software repositories.

Recommendation

• Immediately stop updating to Litellm versions 1.82.7 and 1.82.8.
• Revert to a known-good version of Litellm prior to 1.82.7.
• Analyze network connections for suspicious traffic originating from systems where the compromised Litellm versions were installed, using network connection logs.
• Monitor process creations for suspicious processes spawned from Python executables where Litellm is installed, using process creation logs and the Sigma rules provided below.
• Investigate systems where Litellm 1.82.7 or 1.82.8 were installed for any signs of compromise.
• Review the blog post at https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/ for further details on the compromise.

Attack Chain

1. The attacker sends a crafted HTTP Authorization header to a LiteLLM API endpoint (e.g., /chat/completions).
2. The LiteLLM proxy receives the request and extracts the API key from the Authorization header.
3. Due to insufficient sanitization, the API key value is directly concatenated into a SQL query string.
4. The vulnerable SQL query is executed against the proxy’s database.
5. The attacker injects SQL code to read sensitive data, such as user credentials or API keys, from the database.
6. The attacker may further inject SQL code to modify data, potentially granting themselves administrative privileges or compromising other users’ accounts.
7. The attacker gains unauthorized access to the LiteLLM proxy.
8. 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.

Attack Chain

1. An attacker authenticates to the LiteLLM proxy server using a valid API key.
2. The attacker crafts a malicious prompt template containing SSTI payloads.
3. The attacker sends a POST request to the /prompts/test endpoint, including the crafted template in the request body.
4. The LiteLLM proxy server receives the request and processes the template without proper sanitization.
5. The SSTI payload executes arbitrary code within the LiteLLM proxy process.
6. The attacker gains access to environment variables containing sensitive information, such as API keys and database credentials.
7. The attacker uses the exposed credentials to gain unauthorized access to external services or data.
8. 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.

Attack Chain

1. Attacker authenticates to the LiteLLM proxy with a valid, but low-privilege, API key.
2. 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.
3. 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.
4. The LiteLLM proxy receives the request and, due to the vulnerability, attempts to connect to the supplied server configuration.
5. The proxy spawns the supplied command as a subprocess on the proxy host, using the privileges of the proxy process.
6. The attacker-supplied command executes arbitrary code on the host.
7. 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).