CVE-2024-53981: python-multipart DoS Vulnerability

CVE-2024-53981 Overview

CVE-2024-53981 is a Denial of Service (DoS) vulnerability in python-multipart, a streaming multipart parser for Python commonly used in web frameworks like FastAPI and Starlette. The vulnerability exists in how the parser handles data before the first boundary and after the last boundary in multipart form data. When parsing form data, python-multipart skips line breaks (CR \r or LF \n) in front of the first boundary and any tailing bytes after the last boundary one byte at a time, emitting a log event for each byte processed.

Critical Impact

An attacker can send malicious requests with large amounts of data before the first or after the last multipart boundary, causing excessive logging that results in high CPU load and event loop stalling. In ASGI applications, this can prevent other requests from being processed, leading to a complete denial of service.

Affected Products

• python-multipart versions prior to 0.0.18
• ASGI-based Python web applications using vulnerable python-multipart versions
• Applications built on frameworks that depend on python-multipart (e.g., FastAPI, Starlette)

Discovery Timeline

• 2024-12-02 - CVE CVE-2024-53981 published to NVD
• 2024-12-02 - Last updated in NVD database

Technical Details for CVE-2024-53981

Vulnerability Analysis

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The core issue stems from the multipart parser's handling of data outside the expected boundary delimiters in HTTP multipart form submissions. When the parser encounters bytes before the first boundary or after the final boundary, it processes each byte individually and generates a warning log message for each one. This design flaw creates an algorithmic complexity vulnerability where the processing cost grows linearly with the amount of malicious padding data an attacker includes.

The attack is particularly severe for ASGI (Asynchronous Server Gateway Interface) applications because the excessive processing occurs synchronously within the event loop. This means a single malicious request can monopolize the event loop, blocking all other concurrent request handling and effectively denying service to legitimate users.

Root Cause

The root cause lies in the MultipartState.END state handling within the multipart parser. When the parser reaches the end state after processing the final boundary, it continues to iterate through any remaining bytes one at a time, logging a warning message for each byte. This creates a resource exhaustion scenario where an attacker can force the server to generate millions of log entries and consume excessive CPU cycles by simply appending large amounts of garbage data after the last boundary.

The vulnerable code path executed for each trailing byte, emitting individual log warnings without any rate limiting or optimization for bulk skipping of irrelevant data.

Attack Vector

The attack can be executed remotely over the network without authentication. An attacker crafts a malicious multipart/form-data HTTP request containing:

1. A valid multipart structure with proper boundaries
2. Large amounts of arbitrary data appended after the final --boundary-- terminator

When the server processes this request, the parser enters an inefficient loop that processes the trailing data byte-by-byte with logging, causing:

• Excessive CPU consumption
• Log file bloat
• Event loop stalling in async applications
• Denial of service to concurrent requests

The fix introduced in version 0.0.18 (and refined in 0.0.19) optimizes the end state handling to properly skip CRLF sequences and bulk-skip remaining data:

                elif state == MultipartState.END:
                    # Don't do anything if chunk ends with CRLF.
                    if c == CR and i + 1 < length and data[i + 1] == LF:
                        i += 2
                        continue
                    # Skip data after the last boundary.
                    self.logger.warning("Skipping data after last boundary")
                    i = length

Source: GitHub Commit Details

This patch ensures that after encountering the end state, the parser skips directly to the end of the data buffer (i = length) rather than iterating through each byte, and properly handles trailing CRLF without logging.

Detection Methods for CVE-2024-53981

Indicators of Compromise

• Abnormally large multipart/form-data requests with significant data after boundary terminators
• Sudden spikes in log volume containing repeated "Skipping data after last boundary" warnings
• Increased CPU utilization on web application servers processing multipart form data
• Request timeouts and degraded response times for legitimate users

Detection Strategies

• Monitor web application logs for repetitive warning messages from the multipart parser indicating boundary skipping operations
• Implement request size limits and rate limiting at the reverse proxy or WAF layer to prevent oversized multipart submissions
• Deploy application performance monitoring (APM) to detect CPU spikes correlated with multipart form processing
• Analyze network traffic for unusually large POST requests with multipart/form-data content type

Monitoring Recommendations

• Configure alerting for sustained CPU utilization spikes on application servers
• Set up log aggregation rules to detect high-frequency occurrences of multipart parsing warnings
• Monitor event loop latency metrics in ASGI applications for signs of blocking operations
• Track request queue depths to identify service degradation patterns

How to Mitigate CVE-2024-53981

Immediate Actions Required

• Upgrade python-multipart to version 0.0.18 or later immediately
• Review and update all Python web applications that depend on python-multipart
• Implement request body size limits at the web server or reverse proxy level
• Enable rate limiting to prevent rapid submission of malicious requests

Patch Information

The vulnerability is fixed in python-multipart version 0.0.18. The fix modifies the end state handling to efficiently skip remaining data after the last boundary without per-byte logging. The patch is available via the GitHub Commit and the full security advisory is documented at the GitHub Security Advisory GHSA-59g5-xgcq-4qw3.

To update python-multipart, run:

pip install --upgrade python-multipart>=0.0.18

Workarounds

• Implement strict request body size limits using reverse proxy configuration (e.g., Nginx client_max_body_size)
• Deploy a Web Application Firewall (WAF) with rules to inspect and limit multipart form data sizes
• Configure rate limiting at the application gateway to throttle excessive requests from single sources
• If immediate patching is not possible, consider temporarily disabling multipart form handling for non-essential endpoints

# Nginx configuration example to limit request body size
# Add to server or location block
client_max_body_size 10m;
client_body_buffer_size 128k;

# Rate limiting configuration
limit_req_zone $binary_remote_addr zone=multipart_limit:10m rate=10r/s;
location /upload {
    limit_req zone=multipart_limit burst=20 nodelay;
    # ... other configuration
}