Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify endpoint accepting multipart file uploads
-
ExploitSend multipart upload with base64 Content-Transfer-Encoding
-
ExecutionParser buffers full payload in memory ignoring FILE_UPLOAD_MAX_MEMORY_SIZE
-
ImpactExhaust server memory causing denial of service
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | The target Django application must process multipart/form-data file uploads via django.http.multipartparser.MultiPartParser (the default request handling path whenever an endpoint accepts file uploads). The attacker sends an upload with the header Content-Transfer-Encoding: base64; per the vendor release notes the base64-encoded content is then buffered entirely in memory regardless of the FILE_UPLOAD_MAX_MEMORY_SIZE setting before being passed to upload handlers. Per the CVSS vector no authentication (PR:N) and no user interaction (UI:N) are required. The main limiting factor is reachability: exploitation requires an endpoint that actually accepts file uploads - applications with no upload-accepting views are not exposed - and the impact is bounded memory exhaustion (availability only, rated low by the vendor) rather than code execution or data disclosure. |
| Impact | This is a genuine but modest-priority issue, best characterized as a high-reachability, low-impact denial-of-service. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) scores 6.9 and confirms the flaw is remotely reachable with low complexity, no authentication (PR:N) and no user interaction - meaning any unauthenticated client that can reach an endpoint accepting multipart file uploads can trigger it. However, impact is confined to availability at the Low level (VA:L; VC:N/VI:N/VA:L), consistent with memory pressure rather than service crash, and Django's own security policy rates the issue severity 'low.' There is no EPSS score, no CISA KEV listing, and no PoC or exploit reference in the input - only vendor patch commits - so the real-world exploitation signal is weak despite easy theoretical reachability. The vuln.today decision label is 'this_month,' not act_now or emergency, which aligns with the signals: easy to trigger, but bounded resource-exhaustion impact rather than RCE or data exposure. Net assessment: patch on a routine monthly cadence; this is not a high-CVSS-but-unreachable paper tiger, nor is it an emergency - it is a real, easily-reached, low-severity DoS. |
| Exploit ScenarioDerived | An unauthenticated attacker locates a Django endpoint that accepts multipart/form-data file uploads and sends a crafted upload using Content-Transfer-Encoding: base64. Because the base64-encoded body is buffered entirely in memory regardless of the FILE_UPLOAD_MAX_MEMORY_SIZE setting before being handed to upload handlers, a sufficiently large payload (or many concurrent requests) drives up memory consumption on the server. No PoC or exploit code is referenced in the available data; the attack follows directly from the network vector (AV:N) and low complexity (AC:L/AT:N) described by the CVSS metrics. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Nov 03, 2026
Memory exhaustion in Django's MultiPartParser affects Django 6.1 before 6.1.3, 6.0.4 before 6.0.10, and 5.2.13 before 5.2.19 when an endpoint accepts multipart file uploads carrying Content-Transfer-Encoding: base64. Remote attackers can send such an upload without authentication or user interaction, causing the base64 content to be buffered entirely in memory regardless of FILE_UPLOAD_MAX_MEMORY_SIZE before upload handlers receive it. Impact is availability-only and rated low by the vendor; no public exploit is identified at time of analysis.
RemediationAI
Vendor-released patch: upgrade to Django 6.1.3, 6.0.10, or 5.2.19, as applicable to the deployed branch. The fixes are documented in the Django security release announcement at https://www.djangoproject.com/weblog/2026/nov/03/security-releases/ and the security release index at https://docs.djangoproject.com/en/dev/releases/security/; the corresponding upstream commits are 5d95d9236fa4ededfb1931c60a65432385ece85f, 8b435411f11d69a0dd41a8837654323502e6058e, a29ee4a55acedbe7ba0cb4d2db28c4e4d2848e02, and 4bd1f59a80adafddbd47527c66d92d6a224244d8. No workaround is documented in the available references.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is CWE-770 (allocation of resources without limits or throttling) in django.http.multipartparser.MultiPartParser. Django's multipart parser handles Content-Transfer-Encoding: base64 by decoding uploaded field data; the vulnerable code aligned base64 chunks by reading ahead into the stream, which allowed the full base64 payload to accumulate in memory before being passed to upload handlers, bypassing the FILE_UPLOAD_MAX_MEMORY_SIZE threshold. The fix carries the trailing 1-3 bytes of a partial base64 group into the next chunk instead of reading ahead and raises MultiPartParserError when leftover bytes indicate truncated data. The trigger requires an application endpoint that actually parses multipart file uploads; applications with no upload-accepting views are not exposed. Django's release notes classify the security severity as low.
Know when Django gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Remote, unauthenticated, low-complexity reach to any upload endpoint (AV:N/AC:L/PR:N/UI:N); impact is availability-only and partial memory exhaustion, so A:L and C:N/I:N.
Primary rating from Vendor (DSF).
CVSS VectorVendor: DSF
Lifecycle Timeline
2DescriptionCVE.org
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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
The package python/cpython from 0 and before 3.6.13, from 3.7.0 and before 3.7.10, from 3.8.0 and before 3.8.8, from 3.9
In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for
An issue was discovered in Django 3.2 before 3.2.14 and 4.0 before 4.0.6. Rated critical severity (CVSS 9.8), this vulne
Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input
Django before 1.11.27, 2.x before 2.2.9, and 3.x before 3.0.1 allows account takeover. Rated critical severity (CVSS 9.8
An authentication/authorization bypass in the djust Python live-view framework (versions prior to 1.0.7) lets unauthenti
Unauthenticated arbitrary Python module import in djust before 1.0.7 lets any client that can reach the WebSocket or SSE
Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a
Cross-site scripting (XSS) vulnerability in the dismissChangeRelatedObjectPopup function in contrib/admin/static/admin/j
Forged content modification in django-page-cms through 2.0.13 lets unauthenticated remote attackers exploit five CSRF-ex
Cross-site request forgery in djust's Server-Sent-Events transport affects all versions prior to 1.0.7 and allows a cros
Unauthenticated remote attackers can read live Django view and session state and invoke server-side handlers through dju
EUVD-2026-116018
NVD
CVE.org
GitHub
Exploit-DB