CVE-2026-33033: 
Django vulnerability analysis and mitigation

CVE-2026-33033 is a Denial of Service (DoS) vulnerability in Django's MultiPartParser component that allows remote attackers to degrade server performance by submitting multipart uploads with Content-Transfer-Encoding: base64 headers containing excessive whitespace. It affects Django versions 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30; earlier unsupported series (5.0.x, 4.1.x, 3.2.x) were not formally evaluated but may also be affected. The vulnerability was reported by Seokchan Yoon and disclosed on April 7, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory, Django Blog).

The root cause is classified as CWE-407 (Inefficient Algorithmic Complexity) and CWE-1286 (Improper Validation of Syntactic Correctness of Input). Django's MultiPartParser fails to adequately validate or limit the amount of whitespace present in Content-Transfer-Encoding: base64 encoded multipart upload data, causing the parser to perform excessive computational work when processing such requests. An attacker with low-privilege network access can craft and submit malicious multipart HTTP requests to any Django endpoint that accepts file uploads, triggering worst-case algorithmic behavior without requiring user interaction. A public proof-of-concept exploit script (exploit.py) is available that sends crafted HTTP requests to a target upload endpoint (GitHub Advisory, PoC Repository).

Successful exploitation causes significant performance degradation of the Django application server, effectively resulting in a Denial of Service condition. There is no confidentiality or integrity impact — the vulnerability is limited to availability. Repeated or concurrent malicious requests could exhaust server resources, making the application unresponsive to legitimate users. IBM Storage Defender - Resiliency Service is also identified as an affected downstream product (GitHub Advisory, IBM Advisory).

A public proof-of-concept exploit is available on GitHub (by the original reporter, Seokchan Yoon), consisting of a runnable Python script that sends crafted multipart requests to a vulnerable Django endpoint (PoC Repository). The exploit requires only low-privilege authenticated access and no user interaction, lowering the barrier for abuse. As of the time of reporting, there is no confirmed evidence of in-the-wild exploitation, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.098%, indicating a low but non-negligible probability of exploitation in the near term (GitHub Advisory).

1. Reconnaissance: Identify Django-powered web applications that accept multipart file uploads (e.g., endpoints with file upload forms). Confirm the Django version is in the affected range (4.2.x < 4.2.30, 5.2.x < 5.2.13, or 6.0.x < 6.0.4) via error pages, HTTP headers, or other fingerprinting techniques.
2. Craft malicious multipart request: Construct an HTTP POST request targeting a file upload endpoint. Set the Content-Transfer-Encoding header to base64 and include a payload body with an excessive amount of whitespace characters interspersed within the base64-encoded data.
3. Send the request: Submit the crafted request to the target endpoint using a tool such as curl, requests (Python), or the public PoC script: python exploit.py --target http://<target>/upload.
4. Repeat to amplify impact: Send multiple concurrent or sequential malicious requests to maximize server resource exhaustion, causing the Django application to become slow or unresponsive to legitimate users (PoC Repository, GitHub Advisory).

• Network: Unusual volume of HTTP POST requests to file upload endpoints from a single or small set of source IPs; requests with abnormally large Content-Transfer-Encoding: base64 bodies containing excessive whitespace.
• Logs: Django/web server access logs showing repeated POST requests to upload endpoints with unusually large request bodies or abnormal processing times; elevated error rates or timeouts in application logs.
• Process/System: Sustained high CPU utilization by the Django/Python worker processes without a corresponding increase in legitimate traffic; worker process queues backing up or timing out.
• Application: Increased response latency or HTTP 503/504 errors from the Django application during periods of crafted upload activity.

Upgrade Django to the patched versions: 4.2.30, 5.2.13, or 6.0.4. As interim workarounds, implement rate limiting on multipart upload endpoints to restrict the number of requests per client, and consider adding WAF rules or input validation to reject multipart requests with unusual whitespace patterns in Content-Transfer-Encoding headers. Organizations running unsupported Django series (5.0.x, 4.1.x, 3.2.x) should treat those as potentially affected and prioritize upgrading to a supported, patched release (Django Blog, Django Security Releases).

The Django Software Foundation credited Seokchan Yoon with discovering and responsibly reporting the issue, and published a security release announcement on April 7, 2026 (Django Blog). The vulnerability was disclosed via the oss-security mailing list (oss-sec) and prompted rapid patch releases across major Linux distributions including Ubuntu (USN-8154-1, USN-8154-2), openSUSE, SUSE, Fedora, and Mageia. IBM also issued an advisory for affected downstream products. Community response has been measured, consistent with a medium-severity DoS issue with a straightforward patch path.