CVE-2024-8984: Litellm DoS Vulnerability

CVE-2024-8984 Overview

CVE-2024-8984 is a Denial of Service (DoS) vulnerability in berriai/litellm version 1.44.5. Attackers can trigger resource exhaustion by appending characters, such as dashes (-), to the end of a multipart boundary in an HTTP request. The server processes each appended character continuously, consuming excessive CPU and memory until the service becomes unavailable. The flaw requires no authentication and no user interaction, exposing every deployment reachable over the network. The vulnerability maps to [CWE-770: Allocation of Resources Without Limits or Throttling].

Critical Impact
Unauthenticated remote attackers can render litellm proxy instances unavailable with a single crafted multipart HTTP request, disrupting downstream LLM services that depend on the proxy.

Affected Products

litellm version 1.44.5 and earlier
litellm 1.65.4 pre-release builds (dev2, dev6, dev8, nightly)
Deployments using the vulnerable python-multipart dependency chain

Discovery Timeline

2025-03-20 - CVE-2024-8984 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-8984

Vulnerability Analysis

The vulnerability resides in how litellm parses multipart HTTP request boundaries through its python-multipart dependency. Multipart boundaries in RFC 7578 requests delimit form fields, and the parser must scan input to locate boundary markers. When an attacker appends trailing filler characters to a boundary, the parser enters a pathological code path that iterates over each appended byte without imposing bounds. This algorithmic complexity issue leads to unbounded CPU consumption on a single worker thread. Because litellm typically fronts LLM inference endpoints, saturating the proxy blocks all downstream model traffic. The EPSS score of 0.792% indicates measurable exploitation likelihood given the trivial payload construction.

Root Cause

The root cause is missing input validation on multipart boundary length and content in the upstream python-multipart parser used by FastAPI. The parser did not cap boundary size or short-circuit on malformed trailing characters, allowing quadratic or linear scanning behavior on attacker-controlled input. litellm inherited this behavior by pinning vulnerable versions of python-multipart and fastapi-sso in its dependency manifests.

Attack Vector

An unauthenticated attacker sends a crafted HTTP POST request to any endpoint on the litellm proxy that accepts multipart form data. The Content-Type header specifies a multipart/form-data boundary with a long trailing sequence of dashes or similar filler characters. Each request occupies a worker until resources are exhausted. Repeating the request across connections amplifies impact into a full service outage.

text

// Patched dependency pins in pyproject.toml
 rq = {version = "*", optional = true}
 orjson = {version = "^3.9.7", optional = true}
 apscheduler = {version = "^3.10.4", optional = true}
-fastapi-sso = { version = "^0.10.0", optional = true }
+fastapi-sso = { version = "^0.16.0", optional = true }
 PyJWT = { version = "^2.8.0", optional = true }
-python-multipart = { version = "^0.0.9", optional = true}
-cryptography = {version = "^42.0.5", optional = true}
+python-multipart = { version = "^0.0.18", optional = true}
+cryptography = {version = "^43.0.1", optional = true}

// Source: https://github.com/berriai/litellm/commit/4f49f836aa844ac9b6bfbeff27e6f6b2b9cf3f61

Detection Methods for CVE-2024-8984

Indicators of Compromise

Sustained high CPU utilization on litellm proxy processes tied to a single worker or connection
Inbound HTTP requests with Content-Type: multipart/form-data; boundary= values containing long runs of trailing dashes or filler bytes
Growing queue of pending requests and rising 5xx or timeout responses from the proxy
Concentrated request bursts from a single source IP targeting multipart-accepting endpoints

Detection Strategies

Inspect HTTP request headers at the load balancer or WAF for boundary parameter length greater than the RFC-suggested 70-character limit
Alert when python-multipart package versions below 0.0.18 appear in software bills of materials or container image scans
Correlate spikes in litellm worker CPU time with inbound multipart request volume in observability pipelines

Monitoring Recommendations

Log full Content-Type header values on proxy ingress and baseline expected boundary lengths
Track per-connection request duration and terminate connections exceeding reasonable parsing time
Ingest litellm container metrics and access logs into a centralized SIEM for anomaly detection on request-size and latency dimensions

How to Mitigate CVE-2024-8984

Immediate Actions Required

Upgrade litellm to a release that pins python-multipart>=0.0.18 and fastapi-sso>=0.16.0 per commit 4f49f836aa844ac9b6bfbeff27e6f6b2b9cf3f61
Restrict network exposure of the litellm proxy to authenticated internal clients until patching completes
Deploy a WAF rule that rejects multipart boundaries exceeding 70 characters
Enable request-body and header size limits on the fronting reverse proxy or ingress controller

Patch Information

The maintainers addressed the issue by bumping python-multipart from 0.0.9 to 0.0.18 and fastapi-sso from 0.10.0 to 0.16.0. See the GitHub commit update and the Huntr bounty report for technical details.

Workarounds

Place litellm behind a reverse proxy such as nginx that enforces client_max_body_size and rejects malformed Content-Type headers
Apply per-IP rate limiting on multipart endpoints to reduce blast radius from a single source
Terminate worker processes that exceed CPU-time thresholds and use process supervisors to auto-restart the proxy

bash

# nginx boundary length enforcement example
http {
    map $http_content_type $bad_boundary {
        default 0;
        "~*boundary=[^;]{200,}" 1;
    }

    server {
        location / {
            if ($bad_boundary) { return 400; }
            client_max_body_size 10m;
            proxy_pass http://litellm_upstream;
        }
    }
}