CVE-2026-15337
MediumCVSS 5.3Exploitation Probability (EPSS)
Low risk42th percentile - higher than 42% of all known CVEs
Summary
In Django 5.2 before 5.2.17 and 6.0 before 6.0.8, a denial-of-service vulnerability was discovered in django.utils.translation.check_for_language(), which when given many distinct, very long language codes can lead to excessive memory consumption. These codes can reach the function through the django.views.i18n.set_language() view, which is not routed by default. Memory consumption is bounded by the DATA_UPLOAD_MAX_MEMORY_SIZE setting (default 2.5 MB) and the cache holds a fixed maximum number of entries.
Risk Assessment
The risk is the possibility of a DoS attack on Django applications, potentially leading to memory exhaustion and service unavailability.
Recommendation
It is recommended to upgrade Django to version 5.2.17 or 6.0.8 (or later) and monitor memory usage.
Other vulnerabilities in Django
See all- CVE-2016-9014High
Django versions before 1.8.16, 1.9.11, and 1.10.3, when DEBUG is enabled, allow remote attackers to conduct DNS rebinding attacks due to failure to validate the HTTP Host header against ALLOWED_HOSTS.
- CVE-2016-7401High
The cookie parsing code in Django before 1.8.15 and 1.9.x before 1.9.10, when used on a site with Google Analytics, allows remote attackers to bypass an intended CSRF protection mechanism by setting arbitrary cookies.
- CVE-2016-2512High
The utils.http.is_safe_url function in Django before 1.8.10 and 1.9.x before 1.9.3 allows remote attackers to redirect users to arbitrary web sites. This can lead to phishing attacks or potentially cross-site scripting (XSS) attacks via a URL containing basic authentication.
- CVE-2015-5143High
Django versions before 1.4.21, 1.5.x through 1.6.x, 1.7.x before 1.7.9, and 1.8.x before 1.8.3 are vulnerable to denial of service attacks. Attackers can exploit unique session keys to consume session store resources.
- CVE-2014-0474High
In Django versions before 1.4.11, 1.5.x before 1.5.6, 1.6.x before 1.6.3, and 1.7.x before 1.7 beta 2, the FilePathField, GenericIPAddressField, and IPAddressField model field classes do not properly perform type conversion. This may allow remote attackers to have unspecified impact related to 'MySQL typecasting.'
- CVE-2026-5766Medium
An issue was discovered in versions 6.0 before 6.0.5 and 5.2 before 5.2.14 related to ASGI requests that can bypass the `FILE_UPLOAD_MAX_MEMORY_SIZE` limit when the `Content-Length` header is missing or understated. This may lead to large files being loaded into memory, causing service degradation.
- CVE-2026-35192Low
An issue was discovered in versions 6.0 before 6.0.5 and 5.2 before 5.2.14 regarding response headers that do not vary on cookies if a session is not modified, while `SESSION_SAVE_EVERY_REQUEST` is set to `True`. A remote attacker can steal a user's session after that user visits a cached public page.
- CVE-2026-1207Medium
In Django 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28, a vulnerability was found in raster lookups on RasterField (PostGIS only). Remote attackers can inject SQL via the band index parameter.
- CVE-2016-9013Critical
Django versions 1.8.x before 1.8.16, 1.9.x before 1.9.11, and 1.10.x before 1.10.3 use a hardcoded password for a temporary database user, making it easier for remote attackers to gain access to the database server.
- CVE-2026-15920Medium
An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before 6.0.8. django.contrib.admin.utils.display_for_field() renders URLField values as clickable links in the admin without validating the URL. A value stored with an unsafe scheme is displayed as a link on changelist and read-only admin pages, which allows cross-site scripting against staff users who click the link. Exploitation requires the unsafe value to already be stored in the database. URLField validation through a ModelForm or the admin rejects unsafe schemes, so this affects applications that persist URLField data without running model validation, for example through direct queryset writes, deserialization, or bulk import of untrusted input.
Original NVD description (English source)
An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before 6.0.8. `django.utils.translation.check_for_language()` is subject to a potential denial-of-service attack when given many distinct, very long language codes, which are retained as keys in an in-memory cache and consume process memory. Such codes reach the function through the `django.views.i18n.set_language()` view, which is not routed by default. The consumed memory is bounded, since request data is limited by the `DATA_UPLOAD_MAX_MEMORY_SIZE` setting (default 2.5 MB) and the cache holds a fixed maximum number of entries. 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 Jaeyoung Jang for reporting this issue.