CVE-2024-9606: LiteLLM API key leakage

CISO Take

If your organization uses LiteLLM as an LLM gateway or proxy, assume any API keys (OpenAI, Anthropic, Azure, etc.) processed by versions before 1.44.12 are compromised and rotate them immediately. The defective masking means near-complete keys appear in plaintext in any log aggregator, SIEM, or cloud logging service with access to LiteLLM logs. Patch to 1.44.12 and audit who has had read access to application logs.

What is the risk?

Despite a low EPSS score (0.00109), the business risk is disproportionately high for AI-heavy organizations. LiteLLM is a de-facto standard LLM gateway, and API keys logged in near-plaintext are accessible to anyone with log read permissions — a very broad attack surface in most enterprise environments (SIEM operators, DevOps teams, cloud logging services). A compromised LLM API key enables financial fraud (unbounded API spend), data exfiltration via the LLM provider, and lateral movement into other services sharing the same key. The attack is trivial once log access is obtained.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LiteLLM	pip	< 1.44.12	`1.44.12`
51.0K OpenSSF 6.1 6 dependents Pushed 2d ago 38% patched ~38d to patch Full package profile →

Do you use LiteLLM? You're affected.

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.7%

chance of exploitation in 30 days

Higher than 49% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I None

A None

What should I do?

6 steps

IMMEDIATE

Upgrade LiteLLM to >= 1.44.12.
IMMEDIATE

Rotate ALL API keys (OpenAI, Anthropic, Azure OpenAI, etc.) that were ever configured in the affected LiteLLM instance — treat them as fully compromised.
Audit log access: identify who has accessed application logs since LiteLLM deployment; check for anomalous API usage on provider dashboards.
Purge or restrict access to historical logs containing the leaked keys.
DETECTION

Search existing logs for patterns matching API key formats (e.g., 'sk-', 'ant-') to confirm exposure scope.
Implement log scrubbing/DLP controls at the log aggregation layer as defense-in-depth.

How is it classified?

Data Leakage Data Extraction Auth Bypass Framework API Agent AML.T0037 - Data from Local System AML.T0040 - AI Model Inference API Access AML.T0055 - Unsecured Credentials AML.T0083 - Credentials from AI Agent Configuration AML.T0106 - Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

A.6.2.6 - Protection of AI system information

NIST AI RMF

GOVERN 6.2 - Policies and procedures address AI risks to privacy MANAGE 2.2 - Mechanisms to sustain the value of deployed AI are evaluated and applied

OWASP LLM Top 10

LLM06:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2024-9606?

If your organization uses LiteLLM as an LLM gateway or proxy, assume any API keys (OpenAI, Anthropic, Azure, etc.) processed by versions before 1.44.12 are compromised and rotate them immediately. The defective masking means near-complete keys appear in plaintext in any log aggregator, SIEM, or cloud logging service with access to LiteLLM logs. Patch to 1.44.12 and audit who has had read access to application logs.

Is CVE-2024-9606 actively exploited?

No confirmed active exploitation of CVE-2024-9606 has been reported, but organizations should still patch proactively.

How to fix CVE-2024-9606?

1. IMMEDIATE: Upgrade LiteLLM to >= 1.44.12. 2. IMMEDIATE: Rotate ALL API keys (OpenAI, Anthropic, Azure OpenAI, etc.) that were ever configured in the affected LiteLLM instance — treat them as fully compromised. 3. Audit log access: identify who has accessed application logs since LiteLLM deployment; check for anomalous API usage on provider dashboards. 4. Purge or restrict access to historical logs containing the leaked keys. 5. DETECTION: Search existing logs for patterns matching API key formats (e.g., 'sk-', 'ant-') to confirm exposure scope. 6. Implement log scrubbing/DLP controls at the log aggregation layer as defense-in-depth.

What systems are affected by CVE-2024-9606?

This vulnerability affects the following AI/ML architecture patterns: LLM API gateways, multi-provider LLM routing, agent frameworks, RAG pipelines, model serving, AI/ML CI/CD pipelines.

What is the CVSS score for CVE-2024-9606?

CVE-2024-9606 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.71%.

What is the AI security impact?

Affected AI Architectures

LLM API gatewaysmulti-provider LLM routingagent frameworksRAG pipelinesmodel servingAI/ML CI/CD pipelines

MITRE ATLAS Techniques

AML.T0037 Data from Local System

AML.T0040 AI Model Inference API Access

AML.T0055 Unsecured Credentials

AML.T0083 Credentials from AI Agent Configuration

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.6.2.6

NIST AI RMF: GOVERN 6.2, MANAGE 2.2

OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

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 in the logs, exposing a significant amount of the secret key. The issue affects version v1.44.9.

Exploitation Scenario

An adversary with read access to application logs — via a compromised monitoring account, insider threat, or exposed log aggregator — searches LiteLLM log output for API key patterns. Because only the first 5 characters are masked (e.g., 'sk-ab***...rest-of-key-visible'), the attacker reconstructs the full key trivially. The attacker then uses the harvested OpenAI or Anthropic API key to exfiltrate data by querying the LLM with internal documents, run unauthorized model inference at the victim's expense, or pivot to other services using the same credential material. In agentic deployments, the compromised key may grant access to tool-calling capabilities with broad permissions.

Weaknesses (CWE)

CWE-117 Improper Output Neutralization for Logs Primary

CWE-117 — Improper Output Neutralization for Logs: The product constructs a log message from external input, but it does not neutralize or incorrectly neutralizes special elements when the message is written to a log file.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Implementation] Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.

Source: MITRE CWE corpus.