Django vulnerabilities

In Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18, the function django.forms.models.BaseModelFormSet.save_existing_objects() used the presence of a primary key on a submitted form's instance as evidence that the instance belonged to the formset's limiting queryset. An object outside that queryset can be deleted by an authenticated user without permission on the targeted object, via forged management-form data. Models using the default AutoField primary key are not affected.

In Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18, an incomplete fix for CVE-2026-15307 in Django spatial lookups allows an attacker who can supply bytes values to cause the Django process to make network requests via a crafted VRT document referencing an external raster source.

In Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18, the function django.utils.http.parse_header_parameters() is subject to a potential denial-of-service attack due to quadratic time complexity when parsing a value with many separators inside a quoted parameter. An unauthenticated request could reach this parsing through headers such as Accept or Content-Type.

In Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18, the function django.utils.translation.get_supported_language_variant() is subject to a potential denial-of-service attack when processing many distinct, very long language codes, which are retained as keys in an in-memory cache and consume process memory.

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.

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.

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.

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.

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.'

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.

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.

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.

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.

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.

An issue was discovered in Django 6.0 before 6.0.9 and 5.2 before 5.2.18. GeoDjango's django.contrib.gis.geos.GEOSGeometry is subject to a potential denial-of-service when parsing deeply nested GEOMETRYCOLLECTION objects supplied as well-known text (WKT), well-known binary (WKB), or hex-encoded WKB, which triggers unbounded recursion and a segmentation fault in the underlying GEOS library. Spatial field lookups and the django.contrib.gis.forms.GeometryField form field are also affected.

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.

An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before 6.0.8. GeoDjango spatial lookups optimistically parse the right-hand-side value as a raster, allowing a file with attacker-chosen name and contents to be written or an outbound network request to be made. This can lead to remote code execution if the file is written to a location later imported by the application.

An issue was discovered in Django 6.0 before 6.0.7 and 5.2 before 5.2.16 where `DomainNameValidator` does not prohibit newlines in domain names. If an application uses such values in HTTP responses, header injection can occur, although Django itself is protected by `HttpResponse`.

An issue was discovered in Django 6.0 before 6.0.7 and 5.2 before 5.2.16. `django.contrib.gis.gdal.GDALRaster` over-reads its in-memory buffer when constructed from a bytes object, which can disclose adjacent memory or cause service degradation via a potential segmentation fault when the `vsi_buffer` property is accessed.

A vulnerability was discovered in Django 6.0 before 6.0.7 and 5.2 before 5.2.16. `UpdateCacheMiddleware` and the `cache_page()` decorator cache responses that vary on cookies even when the incoming request carries unrelated cookies, allowing remote attackers to read private data from the shared cache.

In Django 5.2 before 5.2.15 and 6.0 before 6.0.6, `django.middleware.cache.UpdateCacheMiddleware` does not match `Cache-Control` response directives case-insensitively. A remote attacker can read responses that were incorrectly cached because their `Cache-Control` directives used uppercase or mixed-case values.

In Django (versions 6.0 before 6.0.6 and 5.2 before 5.2.15), `EmailBackend` fails to prevent reuse of a partially-initialized connection after a failed STARTTLS handshake when `fail_silently=True`. This allows on-path network attackers to read email content in cleartext.

Vulnerability in Django (versions 6.0 before 6.0.6 and 5.2 before 5.2.15) in the `get_signed_cookie` function allows an attacker to use a signed cookie in a different context than intended, by manipulating the cookie name and salt argument. This is due to non-injective salt derivation.

In Django 5.2 before 5.2.15 and 6.0 before 6.0.6, `django.utils.cache.has_vary_header()` does not strip leading or trailing whitespace from `Vary` response header values before comparison. This allows remote attackers to read cached responses via requests to URLs whose responses contain whitespace-padded Vary header values.

In Django 5.2 before 5.2.15 and 6.0 before 6.0.6, `django.middleware.cache.UpdateCacheMiddleware` does not add `Authorization` to the `Vary` response header for requests bearing that header without `Cache-Control: public`. This allows remote attackers to read private cached responses via unauthenticated requests to the same URL.

In Django 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29, the `URLField.to_python()` function calls `urllib.parse.urlsplit()`, which performs NFKC normalization on Windows. For certain Unicode characters, this normalization is disproportionately slow, allowing a remote attacker to cause a denial of service (DoS) by sending large URLs containing these characters.

A SQL injection vulnerability was discovered in Django's `.QuerySet.order_by()` method. The issue occurs when a column alias containing a period is used with `FilteredRelation` and dictionary expansion. Affected versions include 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28; older unsupported series may also be vulnerable.

An SQL injection vulnerability was discovered in Django 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28 in `FilteredRelation` column aliases via control characters. A crafted dictionary with dictionary expansion passed as `**kwargs` to `annotate()`, `aggregate()`, `extra()`, `values()`, `values_list()`, and `alias()` methods can be exploited.

An issue was discovered in Django 4.2 before 4.2.25, 5.1 before 5.1.13, and 5.2 before 5.2.7. The django.utils.archive.extract() function, used by the "startapp --template" and "startproject --template" commands, allows partial directory traversal via an archive with file paths sharing a common prefix with the target directory.

An issue was discovered in Django 4.2 before 4.2.25, 5.1 before 5.1.13, and 5.2 before 5.2.7. QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() are subject to SQL injection in column aliases, when using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to these methods (on MySQL and MariaDB).