CVE-2023-24580: Django Multipart Parser DoS Vulnerability

CVE-2023-24580 Overview

A denial-of-service vulnerability was discovered in the Multipart Request Parser component of Django, a popular Python web framework. The vulnerability exists in Django versions 3.2 before 3.2.18, 4.0 before 4.0.10, and 4.1 before 4.1.7. Attackers can exploit this flaw by sending maliciously crafted multipart form requests containing an excessive number of parts, which can result in resource exhaustion through too many open files or memory depletion.

Critical Impact

This vulnerability enables unauthenticated remote attackers to cause denial-of-service conditions on Django-based web applications by exhausting server resources through crafted multipart form submissions.

Affected Products

• Django 3.2 (versions before 3.2.18)
• Django 4.0 (versions before 4.0.10)
• Django 4.1 (versions before 4.1.7)
• Debian Linux 10.0

Discovery Timeline

• 2023-02-14 - Django Project releases security patches
• 2023-02-15 - CVE CVE-2023-24580 published to NVD
• 2025-03-18 - Last updated in NVD database

Technical Details for CVE-2023-24580

Vulnerability Analysis

This vulnerability (CWE-400: Uncontrolled Resource Consumption) exists in Django's Multipart Request Parser, which handles file uploads and multipart form data submissions. The parser fails to properly limit the number of parts that can be processed in a single multipart request. When an attacker submits a request with an excessive number of parts, the parser attempts to process all of them, consuming server resources without adequate restrictions.

The impact of successful exploitation includes server resource exhaustion through either file descriptor depletion (too many open files) or memory exhaustion. This can render the affected Django application unresponsive, denying service to legitimate users. The attack can be executed remotely over the network without authentication, as it targets the HTTP request parsing layer before any application-level authentication occurs.

Root Cause

The root cause lies in insufficient input validation and resource management within Django's multipart form handling code. The Multipart Request Parser did not enforce adequate limits on the number of parts that could be submitted in a single request. This allows attackers to craft requests with thousands or millions of boundary parts, each of which the parser attempts to handle, leading to resource exhaustion.

Attack Vector

The attack is network-based and can be executed by any unauthenticated remote attacker who can send HTTP requests to the vulnerable Django application. The attacker crafts a multipart/form-data POST request with an abnormally high number of boundary parts. When the Django server receives this request, the Multipart Request Parser processes each part sequentially, opening file handles or allocating memory for each, eventually exhausting system resources.

The vulnerability mechanism involves sending malformed multipart requests to any Django endpoint that processes form submissions. Attackers can craft HTTP POST requests with the Content-Type: multipart/form-data header and include thousands of boundary delimiters. Each boundary triggers the parser to allocate resources, and without proper limits, the accumulated resource usage causes system exhaustion. For detailed technical analysis, refer to the Django Security Release announcement and the OpenWall OSS Security Notice.

Detection Methods for CVE-2023-24580

Indicators of Compromise

• Unusually high number of open file descriptors on web server processes
• Memory consumption spikes on Django application servers during multipart form submissions
• Web server error logs showing "Too many open files" or memory allocation failures
• Abnormally large HTTP POST requests with Content-Type: multipart/form-data

Detection Strategies

• Monitor for HTTP POST requests with multipart/form-data content type that have unusually large Content-Length headers or high part counts
• Implement rate limiting on endpoints that accept file uploads or multipart form submissions
• Configure web application firewalls (WAF) to detect and block requests with excessive boundary delimiters
• Review Django application logs for repeated parsing errors or timeout conditions

Monitoring Recommendations

• Set up alerts for abnormal file descriptor usage on application servers running Django
• Monitor system memory utilization and set thresholds for Django worker processes
• Implement request logging at the reverse proxy or load balancer level to capture multipart request characteristics
• Enable Django's logging for request parsing to identify potential exploitation attempts

How to Mitigate CVE-2023-24580

Immediate Actions Required

• Upgrade Django to patched versions: 3.2.18, 4.0.10, or 4.1.7 or later
• Implement rate limiting at the web server or load balancer level for POST requests
• Configure request body size limits at the reverse proxy (nginx, Apache) level
• Review and limit the DATA_UPLOAD_MAX_NUMBER_FIELDS Django setting

Patch Information

Security patches have been released by the Django Project. Affected users should upgrade to the following versions:

• Django 3.2.x users: Upgrade to 3.2.18 or later
• Django 4.0.x users: Upgrade to 4.0.10 or later
• Django 4.1.x users: Upgrade to 4.1.7 or later

Detailed patch information is available in the Django 4.1 Security Release Notes and the official Django Weblog Security Release. Debian users should also apply updates per the Debian LTS Announcement.

Workarounds

• If immediate patching is not possible, implement strict request size limits at the web server or reverse proxy level
• Configure DATA_UPLOAD_MAX_MEMORY_SIZE and DATA_UPLOAD_MAX_NUMBER_FIELDS to restrictive values
• Use a web application firewall to inspect and limit multipart request complexity
• Consider temporarily disabling file upload functionality on critical endpoints until patches can be applied

# Django settings.py configuration to limit multipart requests
# Add to your settings.py:
# DATA_UPLOAD_MAX_MEMORY_SIZE = 2621440  # 2.5 MB
# DATA_UPLOAD_MAX_NUMBER_FIELDS = 1000   # Maximum number of form fields

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