CVE-2026-108147 in Django
Summary
by MITRE • 11/03/2026
An issue was discovered in Django 6.1 before 6.1.3, 6.0.4 before 6.0.10, and 5.2.13 before 5.2.19. `django.http.multipartparser.MultiPartParser` is subject to excessive memory consumption when processing multipart file uploads with base64 `Content-Transfer-Encoding`, which could be buffered entirely in memory before being passed to upload handlers. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Ignacy Kujawa for reporting this issue.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in Django versions prior to 6.1.3, 6.0.10, and 5.2.19 centers on a critical resource management flaw within the MultiPartParser component responsible for handling multipart form data uploads. This specific issue arises when clients submit file uploads that utilize base64 Content-Transfer-Encoding headers. Under normal circumstances, Django’s upload handlers are designed to process incoming data in chunks or streams to minimize memory footprint. However, due to this implementation defect, the parser fails to properly stream base64-encoded content and instead buffers the entire decoded payload into system memory before passing it to subsequent upload handling mechanisms. This behavior fundamentally contradicts standard practices for processing large file uploads, where incremental processing is essential to maintain application stability under load.
From a technical perspective, this flaw constitutes an inefficient resource allocation pattern that directly leads to excessive memory consumption. When an attacker or even a legitimate user submits a sufficiently large base64-encoded multipart upload, the server must allocate enough RAM to hold the complete decoded file in memory simultaneously. This creates a direct pathway for denial of service attacks through resource exhaustion. The vulnerability is particularly dangerous because it allows remote attackers to trigger high-memory usage without requiring authentication, provided that the application accepts multipart uploads with this specific encoding type. The impact scales linearly or exponentially depending on the size of the uploaded file, potentially causing the Django process to crash due to out-of-memory errors or degrading performance for other users sharing the same server resources by consuming available heap space and triggering aggressive garbage collection cycles.
This vulnerability aligns closely with CWE-400, which describes conditions where a resource is not properly limited before it becomes under control of another actor, leading to exhaustion of that resource. In the context of modern application security frameworks such as MITRE ATT&CK, this behavior can be categorized under T1496 Resource Hijacking, specifically within sub-techniques related to Denial of Service via resource consumption. The attack vector is remote and requires only a single HTTP request with specific headers, making it highly accessible for automated exploitation tools. Furthermore, the lack of streaming support for base64 encoded multipart data represents a deviation from secure coding standards that prioritize resilience against malformed or maliciously crafted input payloads designed to overwhelm server infrastructure.
Mitigation strategies primarily involve upgrading to patched versions of Django as soon as possible. Administrators should ensure their environments are updated to version 5.2.19, 6.0.10, or 6.1.3 and later, which contain the necessary code corrections to restore proper streaming behavior for base64-encoded multipart uploads. For organizations running unsupported older series such as 5.1.x, 5.0.x, or 4.2.x, immediate migration plans should be initiated since these versions were not evaluated in this specific security review and likely retain similar architectural weaknesses regarding memory management during file processing. Additionally, implementing web application firewalls with rules that limit the maximum size of multipart uploads can provide a temporary layer of defense by preventing excessively large payloads from reaching the Django application logic altogether. Monitoring server memory usage metrics for sudden spikes correlated with upload endpoints can also aid in early detection and response to potential exploitation attempts before significant service disruption occurs.