A flaw was found in Django. The Trunc() and Extract() database functions are subject to SQL injection if untrusted data is used as a kind/lookupname value.

QuerySet.explain() method was subject to SQL injection in option names, using a suitably crafted dictionary, with dictionary expansion, as the options argument.

This issue has High severity, according to the Django security policy [1].

A denial of service flaw was discovered in Django. This issue occurs when incorrectly handling certain internationalized URLs. A malicious attacker could use this issue to cause a crash, resulting in a denial of service.

A flaw was found in Django. The issue occurs when passing certain inputs to multipart forms, resulting in an infinite loop when parsing files.

A flaw was found in Django. The {% debug %} template tag did not properly encode the current context, posing a Cross-site scripting attack vector (XSS).

QuerySet.annotate(), aggregate(), and extra() methods were subject to SQL injection in column aliases, using a suitably crafted dictionary, with dictionary expansion, as the kwargs passed to these methods.

This issue has High severity, according to the Django security policy [1].

An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input.

django.utils.encoding.uritoiri() was subject to potential denial of service attack via certain inputs with a very large number of Unicode characters.

https://www.djangoproject.com/weblog/2023/sep/04/security-releases/

A memory exhaustion flaw was found in the python-django package. This issue occurs when passing certain inputs, leading to a system crash and denial of service.

:class:~django.core.validators.URLValidator, :func:~django.core.validators.validateipv4address, and :func:~django.core.validators.validateipv46address didn't prohibit leading zeros in octal literals. If you used such values you could suffer from indeterminate SSRF, RFI, and LFI attacks.

:func:~django.core.validators.validateipv4address and :func:~django.core.validators.validateipv46address validators were not affected on Python 3.9.5+.

In Django 3.2 before 3.2.25, 4.2 before 4.2.11, and 5.0 before 5.0.3, the django.utils.text.Truncator.words() method (with html=True) and the truncatewordshtml template filter are subject to a potential regular expression denial-of-service attack via a crafted string. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232 and CVE-2023-43665.

A flaw was found in python-django. The parsed values of the Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial of service vector via excessive memory usage if large header values are sent.

An information-disclosure flaw was found in Django, where the dictsort filter in Django's Template Language did not correctly validate user input. A network attacker could exploit this flaw using a suitably crafted key to force information disclosure or unintended method calls.

Following the fix for CVE-2019-14232, the regular expressions used in the implementation of django.utils.text.Truncator’s chars() and words() methods (with html=True) were revised and improved. However, these regular expressions still exhibited linear backtracking complexity, so when given a very long, potentially malformed HTML input, the evaluation would still be slow, leading to a potential denial of service vulnerability.

The chars() and words() methods are used to implement the truncatecharshtml and truncatewordshtml template filters, which were thus also vulnerable.

The input processed by Truncator, when operating in HTML mode, has been limited to the first five million characters in order to avoid potential performance and memory issues.

HTTP requests for URLs with trailing newlines could bypass an upstream access control based on URL paths.

Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it.

:class:.UserAttributeSimilarityValidator incurred significant overhead evaluating submitted password that were artificially large in relative to the comparison values. On the assumption that access to user registration was unrestricted this provided a potential vector for a denial-of-service attack.

References:

https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.orderby SQL injection if orderby is untrusted input from a client of a web application.

An issue was discovered in Django 3.2 before 3.2.24, 4.2 before 4.2.10, and Django 5.0 before 5.0.2. The intcomma template filter was subject to a potential denial-of-service attack when used with very long strings.

EmailValidator and URLValidator were subject to potential regular expression denial of service attack via a very large number of domain name labels of emails and URLs.

Affected versions: Django main development branch, Django 4.2, Django 4.1, Django 3.2

In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise.