CyberSecBulletin

LiteLLM vulnerabilities

We track 5 vulnerabilities in LiteLLM products. 5 are rated high or critical, and none are known to be exploited. The most recent was published on March 20, 2025.

5vulnerabilities
0critical
5high
0exploited
7.7average CVSS score

Latest LiteLLM vulnerabilities

  • 7.5 High severity

    berriai/litellm: Exposure of Sensitive Information Through Metadata

    CVE-2025-0330BerriAI

    In berriai/litellm version v1.52.1, an issue in proxy_server.py causes the leakage of Langfuse API keys when an error occurs while parsing team settings. This vulnerability exposes sensitive information, including langfuse_secret and langfuse_public_key, which

  • 7.5 High severity

    berriai/litellm: Improper Encoding or Escaping of Output

    CVE-2024-9606BerriAI

    In berriai/litellm before version 1.44.12, the `litellm/litellm_core_utils/litellm_logging.py` file contains a vulnerability where the API key masking code only masks the first 5 characters of the key. This results in the leakage of almost the entire API key i

  • 7.5 High severity

    berriai/litellm: Allocation of Resources Without Limits or Throttling

    CVE-2024-8984BerriAI

    A Denial of Service (DoS) vulnerability exists in berriai/litellm version v1.44.5. This vulnerability can be exploited by appending characters, such as dashes (-), to the end of a multipart boundary in an HTTP request. The server continuously processes each ch

  • 8.8 High severity

    berriai/litellm: Improper Control of Generation of Code

    CVE-2024-6825BerriAIEPSS 1.65%

    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

  • 7.2 High severity

    berriai/litellm: Improper Neutralization of Special Elements used in an SQL Command

    CVE-2024-5225BerriAI

    An SQL Injection vulnerability exists in the berriai/litellm repository, specifically within the `/global/spend/logs` endpoint. The vulnerability arises due to improper neutralization of special elements used in an SQL command. The affected code constructs an