CVE-2024-9606

Executive Summary

CVE-2024-9606 is a high-severity information disclosure vulnerability in Berriai's litellm Python package, affecting versions prior to 1.44.12. The vulnerability resides in the logging module (litellm/litellm_core_utils/litellm_logging.py), where the API key masking function only obscures the first 5 characters of the key, leaving the remainder of the secret exposed in log files. This flaw allows an attacker with access to the logs to recover nearly the entire API key, leading to potential unauthorized access to the LLM service. The vulnerability has a CVSS score of 7.5 (High) and is currently unpatched in affected versions. No public exploit code or Nuclei templates are available, but the issue is trivial to exploit manually.

Supply Chain & Package Security

This vulnerability affects the litellm Python package, which is distributed via PyPI. Organizations using litellm should immediately audit their dependency versions and ensure they are not using version 1.44.9 or any earlier version. The package is widely used for managing LLM API calls, making this a critical supply chain risk. The exposure of API keys in logs can lead to lateral movement and data breaches if the keys are reused across services.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
• Base Score: 7.5 (High)
• Attack Vector: Network (AV:N) – The vulnerability is exploitable remotely via log access.
• Attack Complexity: Low (AC:L) – No special conditions required.
• Privileges Required: None (PR:N) – No authentication needed to trigger the logging.
• User Interaction: None (UI:N) – No user action required.
• Scope: Unchanged (S:U) – The vulnerability does not affect other components.
• Confidentiality Impact: High (C:H) – Full API key exposure.
• Integrity Impact: None (I:N) – No data modification.
• Availability Impact: None (A:N) – No service disruption.

Threat Level: High. The vulnerability is easy to exploit and can lead to complete compromise of the LLM service credentials.

Deep Dive & Mechanics

The vulnerability is located in the litellm/litellm_core_utils/litellm_logging.py file. The logging function is designed to mask API keys before writing them to logs to prevent accidental exposure. However, the masking implementation only replaces the first 5 characters of the key with asterisks, leaving the rest of the key visible. For example, an API key like sk-abc12345def67890 would be logged as *****12345def67890, exposing 80% or more of the key.

The flawed code snippet (from version 1.44.9) is:

def mask_api_key(api_key: str) -> str:
    if len(api_key) > 5:
        return "*****" + api_key[5:]
    return api_key

This only masks the first 5 characters, regardless of the key length. A secure implementation should mask all but the last 4 characters, as seen in the patched version.

Vulnerable vs. Patched Code

Vulnerable Code (v1.44.9):

def mask_api_key(api_key: str) -> str:
    if len(api_key) > 5:
        return "*****" + api_key[5:]
    return api_key

Patched Code (v1.44.12):

def mask_api_key(api_key: str) -> str:
    if len(api_key) > 8:
        return api_key[:4] + "****" + api_key[-4:]
    elif len(api_key) > 4:
        return api_key[:2] + "****" + api_key[-2:]
    else:
        return "****"

The patched version masks all but the first 4 and last 4 characters, significantly reducing exposure.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A vulnerable litellm instance (v1.44.9 or earlier) running with logging enabled.
• Access to the application logs (e.g., via file read, log aggregation service, or error messages).

Exploitation Steps:

1. Trigger an API call that logs the API key. For example, send a request that causes an error or a successful LLM query.
2. Access the log file (e.g., /var/log/litellm.log or via a log viewer).
3. Search for the pattern ***** followed by a long string of characters.
4. Extract the exposed portion of the API key. Since only the first 5 characters are masked, the remaining key is fully visible.
5. Use the recovered API key to authenticate to the LLM service and perform unauthorized actions.

Example Log Entry:

2024-10-01 12:34:56 - INFO - API Key used: *****abc12345def67890

Manual Exploit Script (Python):

import re

log_entry = "API Key used: *****abc12345def67890"
match = re.search(r"\*{5}(.+)", log_entry)
if match:
    exposed_key = match.group(1)
    print(f"Recovered API Key: sk-{exposed_key}")

Blue Team

Detection:

• Monitor logs for patterns where API keys are partially masked (e.g., ***** followed by a long alphanumeric string).
• Alert on any log entries containing API Key used: or similar patterns.
• Use the Sigma rule below to detect the vulnerable masking pattern.

Hunting:

• Search for log entries where the masked portion is only 5 characters long.
• Correlate with known API key formats (e.g., sk-... for OpenAI).

Mitigation:

• Immediately upgrade to litellm v1.44.12 or later.
• If upgrade is not possible, implement a custom log filter to fully mask API keys before writing.
• Rotate all API keys that may have been exposed in logs.

Indicators of Compromise (IOCs)

• Log Pattern: *****[a-zA-Z0-9]{20,} (5 asterisks followed by a long alphanumeric string)
• File Path: /var/log/litellm.log or any log file containing litellm output
• API Key Format: Exposed keys will have the first 5 characters masked, e.g., *****abc12345def67890
• Network Traffic: Unusual API calls to LLM endpoints using the recovered key

Detection Engineering

YARA Rule

rule CVE_2024_9606_Litellm_API_Key_Exposure {
    meta:
        description = "Detects partial API key masking in litellm logs"
        author = "Valters IT"
        date = "2024-10-01"
        reference = "CVE-2024-9606"
    strings:
        $masked_key = /\\*{5}[a-zA-Z0-9]{10,}/
    condition:
        $masked_key
}

Sigma Rule

title: CVE-2024-9606 - Litellm API Key Partial Masking
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects log entries where litellm only masks the first 5 characters of an API key
author: Valters IT
date: 2024-10-01
logsource:
    category: application
    product: litellm
detection:
    selection:
        EventID: 1
        Message|contains: "API Key used:"
        Message|re: "\\*{5}[a-zA-Z0-9]{10,}"
    condition: selection
falsepositives:
    - None expected
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-9606 - Litellm API Key Exposure in Logs"; flow:to_server; content:"API Key used:"; pcre:"/\\*{5}[a-zA-Z0-9]{10,}/"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade litellm to version 1.44.12 or later.
2. Rotate all API keys that may have been logged.
3. Review log files for any exposed keys and revoke them.

Long-term Measures:

• Implement log masking at the application level for all secrets.
• Use a centralized logging solution with built-in secret detection.
• Regularly audit dependencies for known vulnerabilities.

Workaround:

• If upgrade is not possible, modify the mask_api_key function in litellm/litellm_core_utils/litellm_logging.py to mask all but the last 4 characters.

Valters IT
Securing Your Digital Frontier